From lemonade-bounces@ietf.org Wed Feb 07 15:54:29 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HEtoA-0000zI-OF; Wed, 07 Feb 2007 15:54:26 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HEtky-00058d-1H; Wed, 07 Feb 2007 15:51:08 -0500 Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HEtkv-0002d6-6s; Wed, 07 Feb 2007 15:51:07 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id 4AF3517616; Wed, 7 Feb 2007 20:50:03 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1HEtjv-0001bk-1a; Wed, 07 Feb 2007 15:50:03 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Wed, 07 Feb 2007 15:50:03 -0500 X-Spam-Score: -2.5 (--) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Cc: lemonade@ietf.org Subject: [lemonade] I-D ACTION:draft-ietf-lemonade-deployments-05.txt X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Enhancements to Internet email to Support Diverse Service Environments Working Group of the IETF. Title : Deployment Considerations for lemonade-compliant Mobile Email Author(s) : R. Gellens Filename : draft-ietf-lemonade-deployments-05.txt Pages : 12 Date : 2007-2-7 This document discusses deployment issues and describes requirements for successful deployment of mobile email which are implicit in the IETF lemonade documents. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-lemonade-deployments-05.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-lemonade-deployments-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-lemonade-deployments-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-2-7114026.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-lemonade-deployments-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-lemonade-deployments-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-2-7114026.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade --NextPart-- From lemonade-bounces@ietf.org Fri Feb 09 14:12:43 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HFbAo-0006bo-Ih; Fri, 09 Feb 2007 14:12:42 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HFbAo-0006bj-3J for lemonade@ietf.org; Fri, 09 Feb 2007 14:12:42 -0500 Received: from usremg02.bea.com ([66.248.192.22]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HFbAm-00070j-L1 for lemonade@ietf.org; Fri, 09 Feb 2007 14:12:42 -0500 Received: from usremr02.bea.com (mailrelay.bea.com [10.160.29.92]) by usremg02.bea.com (Switch-3.2.2/Switch-3.2.2) with ESMTP id l19JCabA032703 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 9 Feb 2007 11:12:36 -0800 Received: from repbex01.amer.bea.com (repbex01.bea.com [10.160.26.98]) by usremr02.bea.com (Switch-3.2.2/Switch-3.2.2) with ESMTP id l19JCStv023355; Fri, 9 Feb 2007 11:12:35 -0800 Received: from 172.24.30.126 ([172.24.30.126]) by repbex01.amer.bea.com ([10.160.26.98]) with Microsoft Exchange Server HTTP-DAV ; Fri, 9 Feb 2007 19:12:34 +0000 User-Agent: Microsoft-Entourage/11.3.3.061214 Date: Fri, 09 Feb 2007 08:08:38 -0600 Subject: Re: [lemonade] About draft-gulbrandsen-imap-notify-02 From: Eric Burger To: Lingyan Wu Message-ID: Thread-Topic: [lemonade] About draft-gulbrandsen-imap-notify-02 Thread-Index: AcdMZI7TzUc6mLhXEdutlQAWy4mm/w== Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.5.0.283055, Antispam-Data: 2007.1.2.131432 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Cc: lemonade@ietf.org X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Do we need to say anything other than, "The server does what the filter says to do"? On 1/23/07 4:42 AM, "Lingyan Wu" wrote: > Hi All, > > In notify-02, there are some new text just like "It does not notify the client > about any events on other mailboxes". > > I accept, it's a waste of both server resources and network traffic to send > events for all accessible mailboxes. > > How about to only send very important and urgent events in unselected mailbox > (e.g. the events that can pass outband-notification filters) through > unsolicited STATUS response including the event--STATUS(EVENT)? > Then we can get such a result: > If client is not connected, the server can send such urgent events through > outband notifications. > If client is connected, the server can send such urgent events in unselected > mailboxes through STATUS(EVENT)(For events in selected mailbox, it's not > necessary to say). > While client is connected only inband notifications shall take place (it means > the server don't send out-band notifications while connection, right?), so > while connection the client can not get urgent events directly in unselected > mailboxes without the extended STATUS responses. > > Maybe you will say, the server can notify client that some events happen in an > unselected mailbox through STATUS(HIGHESTMODSEQ). Yes, it can tell the client > events which happend before connection only through one STATUS(HIGHESTMODSEQ) > responses but for the urgent events which happen after connection > STATUS(EVENT) is more appropriate than STATUS(HIGHESTMODSEQ). > > Any guidance? > > Best Regards, > Lingyan > > > _______________________________________________ > lemonade mailing list > lemonade@ietf.org > https://www1.ietf.org/mailman/listinfo/lemonade _______________________________________________________________________ Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Fri Feb 09 21:12:18 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HFhim-0003sG-I1; Fri, 09 Feb 2007 21:12:12 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HFhik-0003s7-Vu for lemonade@ietf.org; Fri, 09 Feb 2007 21:12:11 -0500 Received: from szxga01-in.huawei.com ([61.144.161.53]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HFhih-0000jp-NN for lemonade@ietf.org; Fri, 09 Feb 2007 21:12:10 -0500 Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0JD8003UO62ZFT@szxga01-in.huawei.com> for lemonade@ietf.org; Sat, 10 Feb 2007 10:11:24 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0JD80010R62ZMI@szxga01-in.huawei.com> for lemonade@ietf.org; Sat, 10 Feb 2007 10:11:23 +0800 (CST) Received: from w48795 ([10.164.120.78]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0JD800DOO62XL2@szxml04-in.huawei.com> for lemonade@ietf.org; Sat, 10 Feb 2007 10:11:23 +0800 (CST) Date: Sat, 10 Feb 2007 10:11:21 +0800 From: Lingyan Wu Subject: Re: [lemonade] About draft-gulbrandsen-imap-notify-02 To: Eric Burger Message-id: <003001c74cb8$c22cae30$4e78a40a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Outlook Express 6.00.2900.2180 Content-type: text/plain; format=flowed; charset=iso-8859-1; reply-type=original Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: X-Spam-Score: 0.5 (/) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db Cc: lemonade@ietf.org X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Lingyan Wu List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Hi Eric, What I said is also that "the server does what the filter says to do". I will mention Type A, Type B and Type C which are defined in "draft-ietf-lemonade-notifications-03". While the client is not connected, the server sends events of Type C through outband notifications. While the client is connected, the server can send events of Type B and Type C in selected mailbox and send events of Type C in unselected mailboxes through STATUS(EVENT). BTW. What I think is based upon the precondition that "while client is connected only inband notifications shall take place". Best Regards, Lingyan ----- Original Message ----- From: "Eric Burger" To: "Lingyan Wu" Cc: Sent: Friday, February 09, 2007 10:08 PM Subject: Re: [lemonade] About draft-gulbrandsen-imap-notify-02 > Do we need to say anything other than, "The server does what the filter > says > to do"? > > > On 1/23/07 4:42 AM, "Lingyan Wu" wrote: > >> Hi All, >> >> In notify-02, there are some new text just like "It does not notify the >> client >> about any events on other mailboxes". >> >> I accept, it's a waste of both server resources and network traffic to >> send >> events for all accessible mailboxes. >> >> How about to only send very important and urgent events in unselected >> mailbox >> (e.g. the events that can pass outband-notification filters) through >> unsolicited STATUS response including the event--STATUS(EVENT)? >> Then we can get such a result: >> If client is not connected, the server can send such urgent events >> through >> outband notifications. >> If client is connected, the server can send such urgent events in >> unselected >> mailboxes through STATUS(EVENT)(For events in selected mailbox, it's not >> necessary to say). >> While client is connected only inband notifications shall take place (it >> means >> the server don't send out-band notifications while connection, right?), >> so >> while connection the client can not get urgent events directly in >> unselected >> mailboxes without the extended STATUS responses. >> >> Maybe you will say, the server can notify client that some events happen >> in an >> unselected mailbox through STATUS(HIGHESTMODSEQ). Yes, it can tell the >> client >> events which happend before connection only through one >> STATUS(HIGHESTMODSEQ) >> responses but for the urgent events which happen after connection >> STATUS(EVENT) is more appropriate than STATUS(HIGHESTMODSEQ). >> >> Any guidance? >> >> Best Regards, >> Lingyan >> >> >> _______________________________________________ >> lemonade mailing list >> lemonade@ietf.org >> https://www1.ietf.org/mailman/listinfo/lemonade > > > _______________________________________________________________________ > Notice: This email message, together with any attachments, may contain > information of BEA Systems, Inc., its subsidiaries and affiliated > entities, that may be confidential, proprietary, copyrighted and/or > legally privileged, and is intended solely for the use of the individual > or entity named in this message. If you are not the intended recipient, > and have received this message in error, please immediately return this > by email and then delete it. > _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Mon Feb 12 02:02:59 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HGVD4-00008E-Ny; Mon, 12 Feb 2007 02:02:46 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HGVD3-0008VK-6X for lemonade@ietf.org; Mon, 12 Feb 2007 02:02:45 -0500 Received: from kalyani.oryx.com ([195.30.37.30]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HGVD1-0002lM-NJ for lemonade@ietf.org; Mon, 12 Feb 2007 02:02:45 -0500 Received: from libertango.oryx.com (libertango.oryx.com [195.30.37.9]) by kalyani.oryx.com (Postfix) with ESMTP id 172084AD31; Mon, 12 Feb 2007 08:02:27 +0100 (CET) Message-Id: Date: Mon, 12 Feb 2007 08:03:31 +0100 From: Arnt Gulbrandsen To: lemonade@ietf.org Subject: Re: [lemonade] draft-gulbrandsen-imap-notify-01 use cases References: <200611221836.21718.martin.konold@erfrakon.de> <56DkrdbKNkPtsPYeN+naTg.md5@libertango.oryx.com> <030701c73e22$76cbb3e0$4e78a40a@china.huawei.com> In-Reply-To: <030701c73e22$76cbb3e0$4e78a40a@china.huawei.com> Content-Type: text/plain; format=flowed MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: Randall Gellens X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Lingyan Wu writes, answering me: >> The STATUS commands are necessary (in this particular case at least) >> to be notified of changes that happened while the client was >> offline. > > Two small methods to save bandwidth as follows: > > 1, If STATUS commands (which are sent after starting NOTIFY) contain > UIDVALIDITY and HIGHESTMODSEQ (catched in client) of related > mailboxes , after receiving the STATUS commands the server can > determine which mailboxes are out of sync and send > STATUS(HIGHESTMODSEQ) responses of the mailboxes to client. > E.g. The client sends 1000 STATUS commands containing UIDVALIDITY and > HIGHESTMODSEQ immediately after starting NOTIFY, the server > determines and sends only a few STATUS(HIGHESTMODSEQ) to client for > those mailboxes out of sync. I don't see real savings. As far as I can tell, you're adding 30 bytes to the status command in order to save 30 bytes on the response. > 2, After receiving Notify command, the server sends unsolicited > STATUS responses for all of the mailboxes to the client. For all of the mailboxes where NewMessage events would be sent, you mean? Maybe that's a good idea. Not 100% sure. Arnt _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Mon Feb 12 02:07:51 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HGVHz-0003uO-AK; Mon, 12 Feb 2007 02:07:51 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HGVHy-0003uJ-0e for lemonade@ietf.org; Mon, 12 Feb 2007 02:07:50 -0500 Received: from kalyani.oryx.com ([195.30.37.30]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HGVHw-0003R4-JG for lemonade@ietf.org; Mon, 12 Feb 2007 02:07:49 -0500 Received: from libertango.oryx.com (libertango.oryx.com [195.30.37.9]) by kalyani.oryx.com (Postfix) with ESMTP id D53D74AD39; Mon, 12 Feb 2007 08:07:48 +0100 (CET) Message-Id: Date: Mon, 12 Feb 2007 08:08:53 +0100 From: Arnt Gulbrandsen To: lemonade@ietf.org Subject: Re: [lemonade] About draft-gulbrandsen-imap-notify-02 References: <02d301c73eeb$e552e440$4e78a40a@china.huawei.com> In-Reply-To: <02d301c73eeb$e552e440$4e78a40a@china.huawei.com> Content-Type: text/plain; format=flowed MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Lingyan Wu writes: > How about to only send very important and urgent events in unselected > mailbox (e.g. the events that can pass outband-notification filters) > through unsolicited STATUS response including the > event--STATUS(EVENT)? I _think_ the latest/next sieve notify draft is close to that. At least if there's a new "imap" mechanism. Which there will be - I'm sure Alexey will write a draft. The sieve notify mechanism then does this: If the filters pass If the user is logged in via IMAP notify via IMAP response else notify outband endif endif So we just need to add text ensuring that IMAP notify and SIEVE notify will not send the same NewMessage event twice. Which will be really easy to implement anyway. Good. Arnt _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Mon Feb 12 03:36:54 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HGWg6-0005oq-2l; Mon, 12 Feb 2007 03:36:50 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HGWg2-0005oZ-Sj for lemonade@ietf.org; Mon, 12 Feb 2007 03:36:46 -0500 Received: from szxga03-in.huawei.com ([61.144.161.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HGWg1-0004uy-Bn for lemonade@ietf.org; Mon, 12 Feb 2007 03:36:46 -0500 Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0JDC00I5KD64WK@szxga03-in.huawei.com> for lemonade@ietf.org; Mon, 12 Feb 2007 16:34:52 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0JDC00NFHD634W@szxga03-in.huawei.com> for lemonade@ietf.org; Mon, 12 Feb 2007 16:34:52 +0800 (CST) Received: from w48795 ([10.164.120.78]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0JDC00C8DD61JR@szxml04-in.huawei.com> for lemonade@ietf.org; Mon, 12 Feb 2007 16:34:51 +0800 (CST) Date: Mon, 12 Feb 2007 16:34:48 +0800 From: Lingyan Wu Subject: Re: [lemonade] draft-gulbrandsen-imap-notify-01 use cases To: Arnt Gulbrandsen Message-id: <007401c74e80$a8997c40$4e78a40a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Outlook Express 6.00.2900.2180 Content-type: text/plain; format=flowed; charset=gb2312; reply-type=response Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <200611221836.21718.martin.konold@erfrakon.de> <56DkrdbKNkPtsPYeN+naTg.md5@libertango.oryx.com> <030701c73e22$76cbb3e0$4e78a40a@china.huawei.com> X-Spam-Score: 0.5 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: lemonade@ietf.org X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Lingyan Wu List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org ----- Original Message ----- From: "Arnt Gulbrandsen" To: Cc: "Lingyan Wu" ; "Randall Gellens" Sent: Monday, February 12, 2007 3:03 PM Subject: Re: [lemonade] draft-gulbrandsen-imap-notify-01 use cases > Lingyan Wu writes, answering me: >>> The STATUS commands are necessary (in this particular case at least) to >>> be notified of changes that happened while the client was offline. >> >> Two small methods to save bandwidth as follows: >> >> 1, If STATUS commands (which are sent after starting NOTIFY) contain >> UIDVALIDITY and HIGHESTMODSEQ (catched in client) of related mailboxes , >> after receiving the STATUS commands the server can determine which >> mailboxes are out of sync and send STATUS(HIGHESTMODSEQ) responses of the >> mailboxes to client. >> E.g. The client sends 1000 STATUS commands containing UIDVALIDITY and >> HIGHESTMODSEQ immediately after starting NOTIFY, the server determines >> and sends only a few STATUS(HIGHESTMODSEQ) to client for those mailboxes >> out of sync. > > I don't see real savings. As far as I can tell, you're adding 30 bytes to > the status command in order to save 30 bytes on the response. Yes. You are right. > >> 2, After receiving Notify command, the server sends unsolicited STATUS >> responses for all of the mailboxes to the client. > > For all of the mailboxes where NewMessage events would be sent, you mean? > Maybe that's a good idea. Not 100% sure. For all of the mailboxes. I meant the server sends STATUS responses for all of the mailboxes without receiving large numbers of STATUS commands first. After receiving the unsolicited STATUS responses, the client can determine which mailboxes are out of sync. > > Arnt > _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Mon Feb 12 04:15:23 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HGXH4-0001rt-UG; Mon, 12 Feb 2007 04:15:02 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HGXH3-0001rk-5l for lemonade@ietf.org; Mon, 12 Feb 2007 04:15:01 -0500 Received: from szxga01-in.huawei.com ([61.144.161.53]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HGXH1-00051v-KJ for lemonade@ietf.org; Mon, 12 Feb 2007 04:15:01 -0500 Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0JDC008LSEZROG@szxga01-in.huawei.com> for lemonade@ietf.org; Mon, 12 Feb 2007 17:14:15 +0800 (CST) Received: from huawei.com ([172.24.1.18]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0JDC00AKXEZRDU@szxga01-in.huawei.com> for lemonade@ietf.org; Mon, 12 Feb 2007 17:14:15 +0800 (CST) Received: from w48795 ([10.164.120.78]) by szxml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0JDC0015KEZQT3@szxml03-in.huawei.com> for lemonade@ietf.org; Mon, 12 Feb 2007 17:14:15 +0800 (CST) Date: Mon, 12 Feb 2007 17:14:14 +0800 From: Lingyan Wu Subject: Re: [lemonade] About draft-gulbrandsen-imap-notify-02 To: lemonade@ietf.org, Arnt Gulbrandsen Message-id: <008e01c74e86$2a63db80$4e78a40a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Outlook Express 6.00.2900.2180 Content-type: text/plain; reply-type=response; charset=gb2312; format=flowed Content-transfer-encoding: QUOTED-PRINTABLE X-Priority: 3 X-MSMail-priority: Normal References: <02d301c73eeb$e552e440$4e78a40a@china.huawei.com> X-Spam-Score: 0.5 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Cc: X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Lingyan Wu List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org ----- Original Message -----=20 =46rom: "Arnt Gulbrandsen" To: Cc: "Lingyan Wu" Sent: Monday, February 12, 2007 3:08 PM Subject: Re: [lemonade] About draft-gulbrandsen-imap-notify-02 > Lingyan Wu writes: >> How about to only send very important and urgent events in unselec= ted=20 >> mailbox (e.g. the events that can pass outband-notification filter= s)=20 >> through unsolicited STATUS response including the event--STATUS(EV= ENT)? > > I _think_ the latest/next sieve notify draft is close to that. At l= east if=20 > there's a new "imap" mechanism. Which there will be - I'm sure Alex= ey will=20 > write a draft. > > The sieve notify mechanism then does this: > > If the filters pass > If the user is logged in via IMAP > notify via IMAP response > else > notify outband > endif > endif Please look at the following definitions. o Filtering results into the following logical types: =A1=EC Type A: Messages filtered out and not accessible by the MEM = Client (no=20 notification, no access) =A1=EC Type B: Messages that are accessible by the MEM Client but n= o outband=20 notification takes place. However, In-band Notifications take place w= hile=20 the MEM Client is connected to MEM Server. =A1=EC Type C: Messages that are accessible by the MEM Client for w= hich=20 notifications (outband or inband) are always sent to the MEM Client. According to the definition, filters for outband seems more strict th= an=20 filters for inband. I mean it seems that the messages passing outband= =20 filters is subset of the messages passing inband filters. Right or no= t? If I misunderstand the definitions, please give corrections and guida= nce. If not, maybe the following mechanism is more appropriate. If the user is logged in via IMAP If the inband filters pass notify via IMAP response endif else If the outband filters pass notify outband endif endif > > So we just need to add text ensuring that IMAP notify and SIEVE not= ify=20 > will not send the same NewMessage event twice. Which will be really= easy=20 > to implement anyway. Good. > > Arnt >=20 _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Mon Feb 12 08:27:20 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HGbDD-0002aj-Tf; Mon, 12 Feb 2007 08:27:19 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HGbDC-0002Xi-R7 for lemonade@ietf.org; Mon, 12 Feb 2007 08:27:18 -0500 Received: from rufus.isode.com ([62.3.217.251]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HGbD9-0003bl-Tw for lemonade@ietf.org; Mon, 12 Feb 2007 08:27:18 -0500 Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Mon, 12 Feb 2007 13:27:13 +0000 Message-ID: <45D06B18.7060606@isode.com> Date: Mon, 12 Feb 2007 13:26:48 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: Lingyan Wu Subject: Re: [lemonade] draft-gulbrandsen-imap-notify-01 use cases References: <200611221836.21718.martin.konold@erfrakon.de> <56DkrdbKNkPtsPYeN+naTg.md5@libertango.oryx.com> <030701c73e22$76cbb3e0$4e78a40a@china.huawei.com> <007401c74e80$a8997c40$4e78a40a@china.huawei.com> In-Reply-To: <007401c74e80$a8997c40$4e78a40a@china.huawei.com> MIME-version: 1.0 Content-type: text/plain; charset="GB2312" Content-transfer-encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: lemonade@ietf.org X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Lingyan Wu wrote: >>> 2, After receiving Notify command, the server sends unsolicited >>> STATUS responses for all of the mailboxes to the client. >> >> For all of the mailboxes where NewMessage events would be sent, you >> mean? Maybe that's a good idea. Not 100% sure. > > For all of the mailboxes. > I meant the server sends STATUS responses for all of the mailboxes > without receiving large numbers of STATUS commands first. After > receiving the unsolicited STATUS responses, the client can determine > which mailboxes are out of sync. Hi Lingyan, Why should the server send STATUS responses for mailboxes not included in the NewMessage event? If the client didn't include some mailboxes in the NewEvent list, it means that the client is not interested in new mail notifications for such mailboxes. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Mon Feb 12 21:06:14 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HGn3C-0005kR-4F; Mon, 12 Feb 2007 21:05:46 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HGn3A-0005kK-9j for lemonade@ietf.org; Mon, 12 Feb 2007 21:05:44 -0500 Received: from szxga01-in.huawei.com ([61.144.161.53]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HGn38-0003kq-Qs for lemonade@ietf.org; Mon, 12 Feb 2007 21:05:44 -0500 Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0JDD00A46PSKJX@szxga01-in.huawei.com> for lemonade@ietf.org; Tue, 13 Feb 2007 10:05:08 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0JDD00DLGPSJU0@szxga01-in.huawei.com> for lemonade@ietf.org; Tue, 13 Feb 2007 10:05:07 +0800 (CST) Received: from w48795 ([10.164.120.78]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0JDD00JCKPSIX6@szxml04-in.huawei.com> for lemonade@ietf.org; Tue, 13 Feb 2007 10:05:07 +0800 (CST) Date: Tue, 13 Feb 2007 10:05:06 +0800 From: Lingyan Wu Subject: Re: [lemonade] draft-gulbrandsen-imap-notify-01 use cases To: Alexey Melnikov Message-id: <008501c74f13$61f0ea60$4e78a40a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Outlook Express 6.00.2900.2180 Content-type: text/plain; reply-type=original; charset=gb2312; format=flowed Content-transfer-encoding: QUOTED-PRINTABLE X-Priority: 3 X-MSMail-priority: Normal References: <200611221836.21718.martin.konold@erfrakon.de> <56DkrdbKNkPtsPYeN+naTg.md5@libertango.oryx.com> <030701c73e22$76cbb3e0$4e78a40a@china.huawei.com> <007401c74e80$a8997c40$4e78a40a@china.huawei.com> <45D06B18.7060606@isode.com> X-Spam-Score: 0.5 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Cc: lemonade@ietf.org X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Lingyan Wu List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org ----- Original Message -----=20 =46rom: "Alexey Melnikov" To: "Lingyan Wu" Cc: "Arnt Gulbrandsen" ; Sent: Monday, February 12, 2007 9:26 PM Subject: Re: [lemonade] draft-gulbrandsen-imap-notify-01 use cases > Lingyan Wu wrote: > >>>> 2, After receiving Notify command, the server sends unsolicited >>>> STATUS responses for all of the mailboxes to the client. >>> >>> For all of the mailboxes where NewMessage events would be sent, y= ou >>> mean? Maybe that's a good idea. Not 100% sure. >> >> For all of the mailboxes. >> I meant the server sends STATUS responses for all of the mailboxes >> without receiving large numbers of STATUS commands first. After >> receiving the unsolicited STATUS responses, the client can determi= ne >> which mailboxes are out of sync. > > Hi Lingyan, > Why should the server send STATUS responses for mailboxes not inclu= ded > in the NewMessage event? If the client didn't include some mailboxe= s in > the NewEvent list, it means that the client is not interested in ne= w > mail notifications for such mailboxes. > > Hi Alexey, Maybe I misunderstood what Arnt said. It should be mailboxes whose events the client wants to get. 1=A1=A2As the following paragraph (beginning with "/////////") said, = the client=20 sends large numbers of STATUS commands for mailboxes immediately afte= r=20 starting NOTIFY and the server sends large numbers of STATUS response= s for=20 these mailboxes. 2=A1=A2What I said meant that the server sends the unsolicited STATUS= responses=20 for these mailboxes directly without receiving the large numbers of S= TATUS=20 commands. ////////////////////////// The NOTIFY command handles that nicely, just one wildcard and hardly = any=20 responses, but the client also has to send 1000 STATUS commands immed= iately=20 after starting NOTIFY, so for a two-hour IMAP connection that's 1001= =20 commands and 2006 responses in order to notify the client of 4 events= .=20 _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Fri Feb 16 13:56:21 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HI8Fg-0000wY-PT; Fri, 16 Feb 2007 13:56:12 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHaz6-0005iB-P4 for lemonade@ietf.org; Thu, 15 Feb 2007 02:24:52 -0500 Received: from gs19.inmotionhosting.com ([205.134.252.251]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HHauO-0001DP-2V for lemonade@ietf.org; Thu, 15 Feb 2007 02:20:01 -0500 Received: from 164.red-80-39-240.dynamicip.rima-tde.net ([80.39.240.164]:51200 helo=[10.9.8.58]) by gs19.inmotionhosting.com with esmtpa (Exim 4.63) (envelope-from ) id 1HHau1-0007xk-1D for lemonade@ietf.org; Wed, 14 Feb 2007 23:19:37 -0800 User-Agent: Microsoft-Entourage/11.3.3.061214 Date: Thu, 15 Feb 2007 08:07:41 +0100 From: Eric Burger To: "lemonade@ietf.org" Message-ID: Thread-Topic: DRAFT Schedule Thread-Index: AcdQz/tsOhO+8rzDEdu+ngAWy4mm/w== Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gs19.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - standardstrack.com X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.5 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c X-Mailman-Approved-At: Fri, 16 Feb 2007 13:56:11 -0500 Subject: [lemonade] DRAFT Schedule X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org MONDAY, March 19, 2007 1740-1950 Afternoon Session III Karlin II APP lemonade THURSDAY, March 22, 2007 0900-1130 Morning Session I Karlin I APP lemonade Draft agenda requests to Eric _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Mon Feb 19 03:33:05 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJ3wy-0001G0-0Z; Mon, 19 Feb 2007 03:32:44 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJ3wv-0001Fd-Ug for lemonade@ietf.org; Mon, 19 Feb 2007 03:32:41 -0500 Received: from kalyani.oryx.com ([195.30.37.30]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HJ3wt-0001AT-GD for lemonade@ietf.org; Mon, 19 Feb 2007 03:32:41 -0500 Received: from libertango.oryx.com (libertango.oryx.com [195.30.37.9]) by kalyani.oryx.com (Postfix) with ESMTP id 74C614AC44; Mon, 19 Feb 2007 09:32:29 +0100 (CET) Message-Id: Date: Mon, 19 Feb 2007 09:34:09 +0100 From: Arnt Gulbrandsen To: lemonade@ietf.org Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; format=flowed MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Subject: [lemonade] New W3C group on HTML in email X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org This announcement by Daniel Glazman ought to be of interest for at least some Lemonade members. Arnt From: Daniel Glazman Following a few personal discussions with friends here in France, and a thread in a W3C Members-only mailing-list, the W3C has decided to launch a new mailing-list for issues related to HTML in email: editing, rendering, interoperability, security, ... The idea is - for instance - to take advantage of the work done by the future HTML WG to have an email-safe profile of HTML. That's only one of the possibilities, just to give you an example. BTW, that includes HTML emails sent from and received by mobile devices, of course... The mailing-list is public-html-mail@w3.org http://lists.w3.org/Archives/Public/public-html-mail/ We also think of having an official W3C workshop on this topic in the coming weeks or months, and we'll ask for position papers. =2E.. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Wed Feb 21 18:29:05 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HK0tK-0000Dn-JX; Wed, 21 Feb 2007 18:28:54 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HK0tK-0000Di-6D for lemonade@ietf.org; Wed, 21 Feb 2007 18:28:54 -0500 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HK0tI-0008AX-RY for lemonade@ietf.org; Wed, 21 Feb 2007 18:28:54 -0500 Received: from totoro.qualcomm.com (totoro.qualcomm.com [129.46.61.158]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id l1LNSjba030598 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 21 Feb 2007 15:28:45 -0800 Received: from [loud.qualcomm.com] (loud.qualcomm.com [129.46.72.21]) by totoro.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id l1LNSi54013327; Wed, 21 Feb 2007 15:28:44 -0800 (PST) Mime-Version: 1.0 Message-Id: In-Reply-To: <003001c74cb8$c22cae30$4e78a40a@china.huawei.com> References: <003001c74cb8$c22cae30$4e78a40a@china.huawei.com> X-Mailer: Eudora for Mac OS X X-message-flag: Warning: Outlook in use. Upgrade to Eudora: Date: Wed, 21 Feb 2007 15:21:26 -0800 To: Lingyan Wu , Eric Burger , Arnt Gulbrandsen From: Randall Gellens Subject: Re: [lemonade] About draft-gulbrandsen-imap-notify-02 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Random-Sig-Tag: 1.0b28 X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: lemonade@ietf.org X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org At 10:11 AM +0800 2/10/07, Lingyan Wu wrote: > BTW. What I think is based upon the precondition that "while client > is connected only inband notifications shall take place". This requires that the notification engine can determine if the user (not any particular client of the user) is logged in. It also opens one timing hole during login when connected clients will get two notifications, one inband and the other outband. This is probably not a problem, as the client should be able to handle this. It also opens a second timing hole during disconnection when the client will not get any notifications. It also opens the issue of client versus user: the server knows users, but it may be clients that care about specific notifications. There was a discussion of these issues at a recent lemonade meeting (maybe DFW?) where there seemed to be some consensus that it is better for outband notifications to always be sent, regardless of connection state. If the client happens to be connected, it can then easily resynchronize. I think the extra cost is duplicate inband notifications, but only for the SELECTED mailbox. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly-selected tag: --------------- Americans can always be counted on to do the right thing, after they have exhausted all other possibilities. -- Winston Churchill _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Thu Feb 22 03:53:52 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HK9hv-0003BJ-9Z; Thu, 22 Feb 2007 03:53:43 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HK9ht-0003B6-Hu for lemonade@ietf.org; Thu, 22 Feb 2007 03:53:41 -0500 Received: from smarthost.yourcomms.net ([195.8.160.124]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HK9ho-0004K3-5t for lemonade@ietf.org; Thu, 22 Feb 2007 03:53:41 -0500 Received: from svr-exchange.avocado.emccsoft.com ([212.248.196.12]) by smarthost.yourcomms.net (8.11.7p3+Sun/8.11.6) with ESMTP id l1M8dYK06182 for ; Thu, 22 Feb 2007 08:39:34 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [lemonade] About draft-gulbrandsen-imap-notify-02 Date: Thu, 22 Feb 2007 08:52:35 -0000 Message-ID: <22C8A0D5D5E095449AB509FE777B5F8003AA1B97@svr-exchange.avocado.emccsoft.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [lemonade] About draft-gulbrandsen-imap-notify-02 thread-index: AcdWEHFM/fkZD9w8SNGACaygdK/DkgATZO0Q References: <003001c74cb8$c22cae30$4e78a40a@china.huawei.com> From: "Ben Last" To: "Randall Gellens" , "Lingyan Wu" , "Eric Burger" , "Arnt Gulbrandsen" X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: lemonade@ietf.org X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org >From: Randall Gellens [mailto:randy@qualcomm.com]=20 >There was a discussion of these issues at a recent lemonade meeting = (maybe DFW?) where there seemed to be >some consensus that it is better for outband notifications to always be = sent, regardless of connection state. Technically, that may well be true. Economically, outband notifications = may incur costs that are not present for (or exceed the costs of) inband = notifications (I'm thinking again of SMS). >If the client happens to be connected, it can then easily = resynchronize. I think the extra cost is duplicate >inband notifications, but only for the SELECTED mailbox. Surely, for any mailbox for which NOTIFY requests have been made? Regards ben Ben Last R & D Manager EMCC Software Ltd _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Thu Feb 22 04:59:15 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HKAiy-0001az-On; Thu, 22 Feb 2007 04:58:52 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HKAix-0001ak-76 for lemonade@ietf.org; Thu, 22 Feb 2007 04:58:51 -0500 Received: from kalyani.oryx.com ([195.30.37.30]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HKAiv-0008St-Ii for lemonade@ietf.org; Thu, 22 Feb 2007 04:58:51 -0500 Received: from libertango.oryx.com (libertango.oryx.com [195.30.37.9]) by kalyani.oryx.com (Postfix) with ESMTP id EA89E4AC2E for ; Thu, 22 Feb 2007 10:58:40 +0100 (CET) Message-Id: Date: Thu, 22 Feb 2007 11:00:35 +0100 From: Arnt Gulbrandsen To: lemonade@ietf.org Subject: Re: [lemonade] About draft-gulbrandsen-imap-notify-02 References: <003001c74cb8$c22cae30$4e78a40a@china.huawei.com> In-Reply-To: Content-Type: text/plain; format=flowed MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: Randall Gellens X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Randall Gellens writes: > At 10:11 AM +0800 2/10/07, Lingyan Wu wrote: > >> BTW. What I think is based upon the precondition that "while client >> is connected only inband notifications shall take place". > > This requires that the notification engine can determine if the user > (not any particular client of the user) is logged in. It also opens > one timing hole during login when connected clients will get two > notifications, one inband and the other outband. This is probably > not a problem, as the client should be able to handle this. It also > opens a second timing hole during disconnection when the client will > not get any notifications. No, that hole is there anyway if you look at the grand scheme of things. Suppose a notification is sent to a laptop client just as the client is reaching for the laptop lid, and is displayed on-screen as the lid is closing, already almost closed, too late for the user to notice. The client receives the event, the user not. In any case, if I've understood the general attitude here correctly, we don't care too much about it: Stray lost notifications are okay as long as there aren't too many. > It also opens the issue of client versus user: the server knows users, > but it may be clients that care about specific notifications. Or it may be users. I've heard use-cases for both. The sieve/metadata/blah notification system towards which I think we're heading heading should support both. (Alexey will talk about this and give some examples in Prague.) Arnt _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Thu Feb 22 18:26:56 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HKNKl-0004YP-Pu; Thu, 22 Feb 2007 18:26:43 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HKNKk-0004YJ-R2 for lemonade@ietf.org; Thu, 22 Feb 2007 18:26:42 -0500 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HKNKj-0006iw-Gp for lemonade@ietf.org; Thu, 22 Feb 2007 18:26:42 -0500 Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id l1MNQdGL025962 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 22 Feb 2007 15:26:40 -0800 Received: from [[192.168.1.13]] (vpn-10-50-0-185.qualcomm.com [10.50.0.185]) by sabrina.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id l1MNQaD3005090; Thu, 22 Feb 2007 15:26:37 -0800 Mime-Version: 1.0 Message-Id: In-Reply-To: <45C09E5A.1080009@isode.com> References: <45BDFF2C.6010505@isode.com> <45C09E5A.1080009@isode.com> X-Mailer: Eudora for Mac OS X X-message-flag: Warning: Outlook in use. Upgrade to Eudora: Date: Thu, 22 Feb 2007 15:25:32 -0800 To: Alexey Melnikov , Philip Guenther From: Randall Gellens Subject: Re: [lemonade] I-D ACTION:draft-ietf-lemonade-reconnect-client-02.txt Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Random-Sig-Tag: 1.0b28 X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: lemonade@ietf.org X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org At 1:49 PM +0000 1/31/07, Alexey Melnikov wrote: > So basically the client can't update its copy of HIGHESTMODSEQ with > FETCH MODSEQ until after it sees the tagged response for the > command. > >> Do we expect connections to drop during resync often enough to be >> worth handling it specially? > > Maybe we don't need to extend CONDSTORE to handle this specially, > but I think it is our duty to properly document how clients can > cope. I agree this needs to be very clear. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly-selected tag: --------------- All programmers are playwrights and all computers are lousy actors. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Thu Feb 22 18:56:16 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HKNnM-0002QZ-43; Thu, 22 Feb 2007 18:56:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HKNnK-0002Hh-UO for lemonade@ietf.org; Thu, 22 Feb 2007 18:56:14 -0500 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HKNnI-0003L2-2C for lemonade@ietf.org; Thu, 22 Feb 2007 18:56:13 -0500 Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id l1MNthoZ029392 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 22 Feb 2007 15:55:44 -0800 Received: from [[192.168.1.13]] (vpn-10-50-0-185.qualcomm.com [10.50.0.185]) by neophyte.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id l1MNtgM5025569; Thu, 22 Feb 2007 15:55:42 -0800 Mime-Version: 1.0 Message-Id: In-Reply-To: <22C8A0D5D5E095449AB509FE777B5F8003AA1B97@svr-exchange.avocado.emccsof t.com> References: <003001c74cb8$c22cae30$4e78a40a@china.huawei.com> <003001c74cb8$c22cae30$4e78a40a@china.h uawei.com> <22C8A0D5D5E095449AB509FE777B5F8003AA1B97@svr-exchange.avocado.emccsof t.com> X-Mailer: Eudora for Mac OS X X-message-flag: Warning: Outlook in use. Upgrade to Eudora: Date: Thu, 22 Feb 2007 15:55:11 -0800 To: "Ben Last" , "Lingyan Wu" , "Eric Burger" , "Arnt Gulbrandsen" From: Randall Gellens Subject: RE: [lemonade] About draft-gulbrandsen-imap-notify-02 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Random-Sig-Tag: 1.0b28 X-Spam-Score: 0.0 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Cc: lemonade@ietf.org X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org At 8:52 AM +0000 2/22/07, Ben Last wrote: > >From: Randall Gellens [mailto:randy@qualcomm.com] >>There was a discussion of these issues at a recent lemonade meeting >> (maybe DFW?) where there seemed to be >>some consensus that it is better for outband notifications to >> always be sent, regardless of connection state. > > Technically, that may well be true. Economically, outband > notifications may incur costs that are not present for (or exceed > the costs of) inband notifications (I'm thinking again of SMS). Very true. Costs as in user charges, as well as network costs, etc. > >If the client happens to be connected, it can then easily > resynchronize. I think the extra cost is duplicate >>inband notifications, but only for the SELECTED mailbox. > > Surely, for any mailbox for which NOTIFY requests have been made? Yes, you are right. At 11:00 AM +0100 2/22/07, Arnt Gulbrandsen wrote: > Randall Gellens writes: >> At 10:11 AM +0800 2/10/07, Lingyan Wu wrote: >> >> BTW. What I think is based upon the precondition that "while >> client is connected ... >> ...snip... >> ... able to handle this. It also opens a second timing hole >> during disconnection when the client will not get any >> notifications. > > No, that hole is there anyway if you look at the grand scheme of > things. Suppose a notification is sent to a laptop client just as > the client is reaching for the laptop lid, and is displayed > on-screen as the lid is closing, already almost closed, too late > for the user to notice. The client receives the event, the user not. In this case, I think the client has likely received the event. I wasn't thinking so much of the user reading any sort of notice as I was about the client receiving and processing events (to decide if it should resynch then or later, and to know if it is out of synch in a mailbox). > In any case, if I've understood the general attitude here > correctly, we don't care too much about it: Stray lost > notifications are okay as long as there aren't too many. Yes, we have (rightly, I think) concluded that we should focus on notifications that are non-critical (since notifications that are in themselves sufficient to resynch require reliability and increased protection against eavesdropping and alteration). > >> It also opens the issue of client versus user: the server knows >> users, but it may be clients that care about specific >> notifications. > > Or it may be users. I've heard use-cases for both. The > sieve/metadata/blah notification system towards which I think we're > heading heading should support both. (Alexey will talk about this > and give some examples in Prague.) -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly-selected tag: --------------- The Law, in its majestic equality, forbids the rich, as well as the poor, to sleep under the bridges, to beg in the streets, and to steal bread. --Anatole France _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Fri Feb 23 03:49:50 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HKW7b-0005GO-WA; Fri, 23 Feb 2007 03:49:43 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HKW7b-0005GJ-JM for lemonade@ietf.org; Fri, 23 Feb 2007 03:49:43 -0500 Received: from smarthost.yourcomms.net ([195.8.160.124]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HKW7a-00069r-2X for lemonade@ietf.org; Fri, 23 Feb 2007 03:49:43 -0500 Received: from svr-exchange.avocado.emccsoft.com ([212.248.196.12]) by smarthost.yourcomms.net (8.11.7p3+Sun/8.11.6) with ESMTP id l1N8ZsK25607 for ; Fri, 23 Feb 2007 08:35:54 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [lemonade] I-D ACTION:draft-ietf-lemonade-reconnect-client-02.txt Date: Fri, 23 Feb 2007 08:48:51 -0000 Message-ID: <22C8A0D5D5E095449AB509FE777B5F8003AA2098@svr-exchange.avocado.emccsoft.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [lemonade] I-D ACTION:draft-ietf-lemonade-reconnect-client-02.txt thread-index: AcdW2RiY5Zb2gtzIRIq+NMbhQfHeNgATJrPg References: <45BDFF2C.6010505@isode.com><45C09E5A.1080009@isode.com> From: "Ben Last" To: "Randall Gellens" , "Alexey Melnikov" , "Philip Guenther" X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: lemonade@ietf.org X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org >From: Randall Gellens [mailto:randy@qualcomm.com]=20 >> Do we expect connections to drop during resync often enough to be=20 >> worth handling it specially? Randy: I think that was your quote - apologies if I have misattributed = it. In our testing of our mobile client, we use a range of mailbox sizes: = some are test and some (the larger) are real-world mailboxes. Like = mine, which is embarrassingly large, and those of a group of test users = who are evaluating the first release of the client. We find that = connection drop during synchronization is actually fairly common. = Naturally, the chances of losing the connection during sync increase = with the size of the mailbox, especially since we find that the client = often needs to do a state-comparison sync after first login, and actual = cellular data rates can be very slow at times. We await the = availability of CONDSTORE with great anticipation... Also: sometimes even a rare condition is worth special case treatment if = the *consequences* of that condition are sufficiently expensive. A full = resync of an inbox with 1000+ email in counts as expensive :) Just for interest, some stuff we've found through mobile phone client = testing: Connection drops occur somewhat more often when the connection is over = WiFi. We're typically finding that mobile phone connectivity over WiFi = suffers because of coverage blackspots that are usually not noticed = because they're in places where people don't take laptops, because = blackspot effects are worse for a phone because transmission power is = lower and because the human body is an effective shield when a phone is = raised to the head or worn in a pocket! Since WiFi is effectively free = compared with cellular data, though, it's the preferred way to connect. Aggressive battery-saving (and cost-saving) measures include dropping = out of push mode during the night, or when roaming. When = re-establishing a connection after a pushless period it's often = necessary to perform a state-comparison sync. Yours meanderingly Ben Ben Last R & D Manager EMCC Software Ltd _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Fri Feb 23 06:56:36 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HKZ2F-0000ph-JO; Fri, 23 Feb 2007 06:56:23 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HKZ2E-0000pb-6m for lemonade@ietf.org; Fri, 23 Feb 2007 06:56:22 -0500 Received: from kalyani.oryx.com ([195.30.37.30]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HKZ28-0001N0-My for lemonade@ietf.org; Fri, 23 Feb 2007 06:56:22 -0500 Received: from lochnagar.oryx.com (unknown [195.30.37.40]) by kalyani.oryx.com (Postfix) with ESMTP id F2C5E4AC22; Fri, 23 Feb 2007 12:56:06 +0100 (CET) Message-Id: <03uCGa5AbeJY8iUrIHiGnQ.md5@lochnagar.oryx.com> Date: Fri, 23 Feb 2007 12:56:05 +0100 From: Arnt Gulbrandsen To: lemonade@ietf.org Subject: Re: [lemonade] About draft-gulbrandsen-imap-notify-02 Content-Type: text/plain; format=flowed MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: Lingyan, Randall Gellens X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Randall Gellens writes: > At 11:00 AM +0100 2/22/07, Arnt Gulbrandsen wrote: >> Randall Gellens writes: >>> It also opens a second timing hole during disconnection when the >>> client will not get any notifications. >> >> No, that hole is there anyway if you look at the grand scheme of >> things. Suppose a notification is sent to a laptop client just as >> the client is reaching for the laptop lid, and is displayed >> on-screen as the lid is closing, already almost closed, too late >> for the user to notice. The client receives the event, the user >> not. > > In this case, I think the client has likely received the event. I > wasn't thinking so much of the user reading any sort of notice as I > was about the client receiving and processing events (to decide if it > should resynch then or later, and to know if it is out of synch in a > mailbox). Doesn't really matter. That decision to resync/read may reasonably rest with the user, ie. we cannot base our work on an assumption that the decision is NOT made by the user. Therefore we have the timing hole, and must learn to live with it. >> In any case, if I've understood the general attitude here correctly, >> we don't care too much about it: Stray lost notifications are okay >> as long as there aren't too many. > > Yes, we have (rightly, I think) concluded that we should focus on > notifications that are non-critical (since notifications that are in > themselves sufficient to resynch require reliability and increased > protection against eavesdropping and alteration). I think we agree but I see the whole thing rather differently ;) Arnt _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Fri Feb 23 13:21:02 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HKf2Q-0007GP-OX; Fri, 23 Feb 2007 13:20:58 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HKf2P-0007GJ-54 for lemonade@ietf.org; Fri, 23 Feb 2007 13:20:57 -0500 Received: from usremg02.bea.com ([66.248.192.22]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HKf2N-0003xK-OM for lemonade@ietf.org; Fri, 23 Feb 2007 13:20:57 -0500 Received: from usremr02.bea.com (mailrelay.bea.com [10.160.29.92]) by usremg02.bea.com (Switch-3.2.2/Switch-3.2.2) with ESMTP id l1NIKrQr021130 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Fri, 23 Feb 2007 10:20:54 -0800 Received: from repbex01.amer.bea.com (repbex01.bea.com [10.160.26.98]) by usremr02.bea.com (Switch-3.2.2/Switch-3.2.2) with ESMTP id l1NIKpJe029354 for ; Fri, 23 Feb 2007 10:20:52 -0800 Received: from 172.24.29.139 ([172.24.29.139]) by repbex01.amer.bea.com ([10.160.26.98]) with Microsoft Exchange Server HTTP-DAV ; Fri, 23 Feb 2007 18:20:51 +0000 User-Agent: Microsoft-Entourage/11.3.3.061214 Date: Fri, 23 Feb 2007 10:39:21 -0500 From: Eric Burger To: "lemonade@ietf.org" Message-ID: Thread-Topic: Draft Agenda Thread-Index: AcdXYMlaB+l2bMNUEdu9zwAWy4mm/w== Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.5.0.283055, Antispam-Data: 2007.2.21.151434 X-Spam-Score: 0.5 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Subject: [lemonade] Draft Agenda X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Monday ====== Agenda Bashing (5 min) Quick Discussions: Convert (10 min) Deployments (10 min) Longer Discussions: Quick Reconnect (20 min) Notifications (60 min) Thursday ======== Agenda Bashing (5 min) SMTP Restart (10 min) IMAP Sieve (10 min) Streaming (10 min) Notifications Conclusion (20 min) Profile-bis (20 min) Marketing (10 min) Views (60 min) Updates & Next Steps (15 min) We will cover document status not needing discussion on the list. This includes: Compress IMAP URL SASL-IR Within _______________________________________________________________________ Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Fri Feb 23 13:21:07 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HKf2H-0007E7-JH; Fri, 23 Feb 2007 13:20:49 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HKf2G-0007E1-Nx for lemonade@ietf.org; Fri, 23 Feb 2007 13:20:48 -0500 Received: from usremg01.bea.com ([66.248.192.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HKf2F-0003w0-9g for lemonade@ietf.org; Fri, 23 Feb 2007 13:20:48 -0500 Received: from usremr02.bea.com (usremr02.bea.com [10.160.29.92]) by usremg01.bea.com (Switch-3.2.2/Switch-3.2.2) with ESMTP id l1NIKjKC017963 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Fri, 23 Feb 2007 10:20:45 -0800 Received: from repbex01.amer.bea.com (repbex01.bea.com [10.160.26.98]) by usremr02.bea.com (Switch-3.2.2/Switch-3.2.2) with ESMTP id l1NIKh5H029315 for ; Fri, 23 Feb 2007 10:20:43 -0800 Received: from 172.24.29.139 ([172.24.29.139]) by repbex01.amer.bea.com ([10.160.26.98]) with Microsoft Exchange Server HTTP-DAV ; Fri, 23 Feb 2007 18:20:43 +0000 User-Agent: Microsoft-Entourage/11.3.3.061214 Date: Fri, 23 Feb 2007 06:52:04 -0500 From: Eric Burger To: Message-ID: Thread-Topic: Asymmetry of limited capability access networks Thread-Index: AcdXWi5fbLWZzcNNEdu9zwAWy4mm/w== In-Reply-To: <007401c74e80$a8997c40$4e78a40a@china.huawei.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.5.0.283055, Antispam-Data: 2007.2.21.151434 X-Spam-Score: 0.2 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Subject: [lemonade] Asymmetry of limited capability access networks X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Just a general comment: Many access networks have asymmetric bandwidth constraints. Examples are ADSL and WiMax. Thus, if all things are equal, bytes on the down-link (S->C) being traded for bytes on the up-link (C->S) is generally a good thing. For the specific case here, 30 bytes at 50kb/s is 6ms (including overheads). Do we really care? On 2/12/07 9:34 AM, "Lingyan Wu" wrote: > > ----- Original Message ----- > From: "Arnt Gulbrandsen" > To: > Cc: "Lingyan Wu" ; "Randall Gellens" > > Sent: Monday, February 12, 2007 3:03 PM > Subject: Re: [lemonade] draft-gulbrandsen-imap-notify-01 use cases > > >> Lingyan Wu writes, answering me: >>>> The STATUS commands are necessary (in this particular case at least) to >>>> be notified of changes that happened while the client was offline. >>> >>> Two small methods to save bandwidth as follows: >>> >>> 1, If STATUS commands (which are sent after starting NOTIFY) contain >>> UIDVALIDITY and HIGHESTMODSEQ (catched in client) of related mailboxes , >>> after receiving the STATUS commands the server can determine which >>> mailboxes are out of sync and send STATUS(HIGHESTMODSEQ) responses of the >>> mailboxes to client. >>> E.g. The client sends 1000 STATUS commands containing UIDVALIDITY and >>> HIGHESTMODSEQ immediately after starting NOTIFY, the server determines >>> and sends only a few STATUS(HIGHESTMODSEQ) to client for those mailboxes >>> out of sync. >> >> I don't see real savings. As far as I can tell, you're adding 30 bytes to >> the status command in order to save 30 bytes on the response. > > Yes. You are right. > >> >>> 2, After receiving Notify command, the server sends unsolicited STATUS >>> responses for all of the mailboxes to the client. >> >> For all of the mailboxes where NewMessage events would be sent, you mean? >> Maybe that's a good idea. Not 100% sure. > > For all of the mailboxes. > I meant the server sends STATUS responses for all of the mailboxes without > receiving large numbers of STATUS commands first. After receiving the > unsolicited STATUS responses, the client can determine which mailboxes are > out of sync. > >> >> Arnt >> > > > > _______________________________________________ > lemonade mailing list > lemonade@ietf.org > https://www1.ietf.org/mailman/listinfo/lemonade _______________________________________________________________________ Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Fri Feb 23 13:23:40 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HKf52-0002R8-CJ; Fri, 23 Feb 2007 13:23:40 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HKf50-0002Qq-3M for lemonade@ietf.org; Fri, 23 Feb 2007 13:23:38 -0500 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HKf4y-0004FB-NT for lemonade@ietf.org; Fri, 23 Feb 2007 13:23:38 -0500 Received: from hamtaro.qualcomm.com (hamtaro.qualcomm.com [129.46.61.157]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id l1NINUjL015805 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 23 Feb 2007 10:23:31 -0800 Received: from [[192.168.1.13]] (vpn-10-50-0-201.qualcomm.com [10.50.0.201]) by hamtaro.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id l1NINP0P023764; Fri, 23 Feb 2007 10:23:28 -0800 (PST) Mime-Version: 1.0 Message-Id: In-Reply-To: <22C8A0D5D5E095449AB509FE777B5F8003AA2098@svr-exchange.avocado.emccsof t.com> References: <45BDFF2C.6010505@isode.com><45C09E5A.1080009@isode.com> <22C8A0D5D5E095449AB509FE777B5F8003AA2098@svr-exchange.avocado.emccsof t.com> X-Mailer: Eudora for Mac OS X X-message-flag: Warning: Outlook in use. Upgrade to Eudora: Date: Fri, 23 Feb 2007 10:19:44 -0800 To: "Ben Last" , "Alexey Melnikov" , "Philip Guenther" From: Randall Gellens Subject: RE: [lemonade] I-D ACTION:draft-ietf-lemonade-reconnect-client-02.txt Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Random-Sig-Tag: 1.0b28 X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Cc: lemonade@ietf.org X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org At 8:48 AM +0000 2/23/07, Ben Last wrote: > >From: Randall Gellens [mailto:randy@qualcomm.com] >>> Do we expect connections to drop during resync often enough to be >>> worth handling it specially? > > Randy: I think that was your quote - apologies if I have misattributed it. It was actually Philip Guenther, I believe. > In our testing of our mobile client, we use a range of mailbox > sizes: some are test and some (the larger) are real-world > mailboxes. Like mine, which is embarrassingly large, and those of > a group of test users who are evaluating the first release of the > client. We find that connection drop during synchronization is > actually fairly common. Naturally, the chances of losing the > connection during sync increase with the size of the mailbox, > especially since we find that the client often needs to do a > state-comparison sync after first login, and actual cellular data > rates can be very slow at times. We await the availability of > CONDSTORE with great anticipation... Thanks for sharing this data, I think it's helpful, and a point we need to keep in mind. I'd be interested to know which cellular data technology is being used, and also what the resynchronization technique is. And naturally, what happens when CONDSTORE and QRESYNCH are used. > Also: sometimes even a rare condition is worth special case > treatment if the *consequences* of that condition are sufficiently > expensive. A full resync of an inbox with 1000+ email in counts as > expensive :) > > Just for interest, some stuff we've found through mobile phone > client testing: > > Connection drops occur somewhat more often when the connection is > over WiFi. We're typically finding that mobile phone connectivity > over WiFi suffers because of coverage blackspots that are usually > not noticed because they're in places where people don't take > laptops, because blackspot effects are worse for a phone because > transmission power is lower and because the human body is an > effective shield when a phone is raised to the head or worn in a > pocket! Since WiFi is effectively free compared with cellular > data, though, it's the preferred way to connect. Very interesting. Thanks for sharing this experience as well. > Aggressive battery-saving (and cost-saving) measures include > dropping out of push mode during the night, or when roaming. When > re-establishing a connection after a pushless period it's often > necessary to perform a state-comparison sync. Good point. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly-selected tag: --------------- Programming Department: Mistakes made while you wait. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Fri Feb 23 17:27:28 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HKisw-0002by-6O; Fri, 23 Feb 2007 17:27:26 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HKist-0002bn-Bd; Fri, 23 Feb 2007 17:27:23 -0500 Received: from zrtps0kp.nortel.com ([47.140.192.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HKisr-0008NZ-Tb; Fri, 23 Feb 2007 17:27:23 -0500 Received: from zcarhxm0.corp.nortel.com (zcarhxm0.corp.nortel.com [47.129.230.95]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l1NMR7s14893; Fri, 23 Feb 2007 17:27:07 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 23 Feb 2007 17:26:44 -0500 Message-ID: <085091CB2CA14E4B8B163FFC37C84E9D0E88A7CA@zcarhxm0.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Notes from the Jan 25th jabber chat on notifications Thread-Index: AcdXmbLw1QT+xFbaT6SO+bULR2p0/A== From: "Glenn Parsons" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: a0ecb232550b38fd41a3cf6a312fbabc Cc: lemonade@ietf.org Subject: [lemonade] Notes from the Jan 25th jabber chat on notifications X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0026096447==" Errors-To: lemonade-bounces@ietf.org This is a multi-part message in MIME format. --===============0026096447== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C75799.B38A86E7" This is a multi-part message in MIME format. ------_=_NextPart_001_01C75799.B38A86E7 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable LEMONADE Notifications chat January 25, 2007 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D Full log: http://www.ietf.org/meetings/ietf-logs/lemonade/2007-01-25.html Online personalities: bernard.desruisseaux=20 eburger - Eric Burger alexeymelnikov Glenn Parsons Dave Cridland Ams - Abhijit Menon-Sen Lisa - Lisa Dusseault Arnt - Arnt Gulbrandsen Rohan - Rohan Mahy Discussion ------------- Current documents: draft-newman-lemonade-msgevent-00 draft-ietf-lemonade-notifications-03 OMA MEM REQ & AD draft-mahy-sieve-notify-sip-00 Types of notifications * out of band * real time * various transport mechanisms - SIEVE, IMAP events, ... Types of out of band notifications * new message notification * new message notification with different degrees of details * mailbox state change notification * file updated Things to decide about notifications: * how to send=20 * who to send to * what to send Concern about clients avoiding sync really being a subvertive IMAPv5 Concern on frequency of SIEVE messages for notifications has been alleviated, however there is still an issue on how to deal with multiple devices. SIEVE scripts (for mobile devices) will tend to be semi-permanent, there was a concern noted that designing for this might prohibit dynamic scripts. SIEVE is obvious for 'user oriented' notifications, but it is overkill for MWI. MWI is already defined using SIP (RFC 3842) but is that necessary for email? Notifications are best-effort. And account related notifications are also out of scope. =20 Consensus: We are only talking about email-related notifications, not calendar notifications, and these can be sent with a number of protocols. =20 Structured notifications or free text? Use cases? Security needed for notifications Focus on MWI first (e.g., using IMAP IDLE), leave the user details to SIEVE draft. That is no subject or other data. However, the SIP MWI already does this - counts are reliable, the other data is not. =20 Consensus: Reuse RFC 3842 - or an XMPP clone of it if necessary, unless a good argument is made to the contrary. Summary: 1. notifications scope is e-mail 2. follow _model_ of RFC 3842 3. figure out transport later ... 4. find a 6 year old editor... ------_=_NextPart_001_01C75799.B38A86E7 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Notes from the Jan 25th jabber chat on notifications

LEMONADE Notifications chat
January 25, 2007
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D

Full log:
= http://www.ietf.org/meetings/ietf-logs/lemonade/2007-01-25.html

Online personalities:

      bernard.desruisseaux
      eburger – Eric Burger
      alexeymelnikov
      Glenn Parsons
      Dave = Cridland
      Ams -  Abhijit = Menon-Sen
      Lisa – Lisa = Dusseault
      Arnt – Arnt = Gulbrandsen
      Rohan – Rohan = Mahy

Discussion
-------------

Current = documents:

      draft-newman-lemonade-msgevent-00
      draft-ietf-lemonade-notifications-03
      OMA MEM REQ & = AD
      draft-mahy-sieve-notify-sip-00

Types of = notifications

  • out of = band
  • real = time
  • various transport = mechanisms – SIEVE, IMAP events, …

Types of out of band = notifications

  • new message = notification
  • new message = notification with different degrees of details
  • mailbox state = change notification
  • file = updated

Things to decide = about notifications:

  • how to send =
  • who to send = to
  • what to = send

Concern about = clients avoiding sync really being a subvertive IMAPv5

Concern on frequency = of SIEVE messages for notifications has been alleviated, however there = is still an issue on how to deal with multiple = devices.

SIEVE scripts (for = mobile devices) will tend to be semi-permanent, there was a concern = noted that designing for this might prohibit dynamic scripts.  = SIEVE is obvious for ‘user oriented’ notifications, but it = is overkill for MWI.  MWI is already defined using SIP (RFC 3842) = but is that necessary for email?

Notifications are = best-effort.  And account related notifications are also out of = scope.
 
Consensus:  We = are only talking about email-related notifications, not calendar = notifications, and these can be sent with a number of protocols.  =

Structured = notifications or free text?

Use = cases?

Security needed for = notifications

Focus on MWI first = (e.g., using IMAP IDLE), leave the user details to SIEVE draft.  = That is no subject or other data.  However, the SIP MWI already = does this – counts are reliable, the other data is = not.  

Consensus:  = Reuse RFC 3842 – or an XMPP clone of it if necessary, unless a = good argument is made to the contrary.


Summary:

  1. notifications scope = is e-mail
  2. follow _model_ of = RFC 3842
  3. figure out = transport later
    …
  4. find a 6 year old = editor…


------_=_NextPart_001_01C75799.B38A86E7-- --===============0026096447== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade --===============0026096447==-- From lemonade-bounces@ietf.org Fri Feb 23 17:50:02 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HKjEf-0003uH-EY; Fri, 23 Feb 2007 17:49:53 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HKjEd-0003u8-L5 for lemonade@ietf.org; Fri, 23 Feb 2007 17:49:51 -0500 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HKjEc-0003vp-8w for lemonade@ietf.org; Fri, 23 Feb 2007 17:49:51 -0500 Received: from hamtaro.qualcomm.com (hamtaro.qualcomm.com [129.46.61.157]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id l1NMni0p029583 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 23 Feb 2007 14:49:44 -0800 Received: from [loud.qualcomm.com] (loud.qualcomm.com [129.46.72.21]) by hamtaro.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id l1NMngYp008546; Fri, 23 Feb 2007 14:49:43 -0800 (PST) Mime-Version: 1.0 Message-Id: In-Reply-To: References: X-Mailer: Eudora for Mac OS X X-message-flag: Warning: Outlook in use. Upgrade to Eudora: Date: Fri, 23 Feb 2007 14:44:09 -0800 To: Eric Burger , From: Randall Gellens Subject: Re: [lemonade] Asymmetry of limited capability access networks Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Random-Sig-Tag: 1.0b28 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org At 6:52 AM -0500 2/23/07, Eric Burger wrote: > For the specific case here, 30 bytes at 50kb/s is 6ms (including overheads). > Do we really care? In general, I'm inclined to suspect that the cost of making any change probably isn't worth saving 30 bytes. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly-selected tag: --------------- Kids Make Nutritious Snacks --Newspaper headline _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Mon Feb 26 03:02:17 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLano-0002tp-Ks; Mon, 26 Feb 2007 03:01:44 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLann-0002tk-GU for lemonade@ietf.org; Mon, 26 Feb 2007 03:01:43 -0500 Received: from smarthost.yourcomms.net ([195.8.160.124]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HLani-0006ZY-4V for lemonade@ietf.org; Mon, 26 Feb 2007 03:01:43 -0500 Received: from svr-exchange.avocado.emccsoft.com ([212.248.196.12]) by smarthost.yourcomms.net (8.11.7p3+Sun/8.11.6) with ESMTP id l1Q7lbK10120 for ; Mon, 26 Feb 2007 07:47:38 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [lemonade] I-D ACTION:draft-ietf-lemonade-reconnect-client-02.txt Date: Mon, 26 Feb 2007 08:00:30 -0000 Message-ID: <22C8A0D5D5E095449AB509FE777B5F8003AF2429@svr-exchange.avocado.emccsoft.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [lemonade] I-D ACTION:draft-ietf-lemonade-reconnect-client-02.txt thread-index: AcdXd5yQkZ7+cI5ISzK8JtdD4PIokQCA/BdA References: <45BDFF2C.6010505@isode.com><45C09E5A.1080009@isode.com> <22C8A0D5D5E095449AB509FE777B5F8003AA2098@svr-exchange.avocado.emccsof t.com> From: "Ben Last" To: "Randall Gellens" , "Alexey Melnikov" , "Philip Guenther" X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: lemonade@ietf.org X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org From: Randall Gellens [mailto:randy@qualcomm.com]=20 >I wrote: >>...We find=20 >> that connection drop during synchronization is actually fairly = common. =20 >I'd be interested to know which cellular data technology is being used, = and also what the >resynchronization technique is. And naturally, what happens when = CONDSTORE and >QRESYNCH are used. GSM :) And usually GRPS for the data, though 3G and WiFi also used = where supported. Dropouts happen with all the bearer technologies: WiFi = that's quite acceptable for laptops in an office often shows many more = blackspots when used with mobiles (due to the fact that mobiles are used = in places that laptops aren't, and spend a lot of time in pockets next = to human bodies). The most common resynch is a state-comparison = resynch, which in this case is a series of FETCH commands for UID and = FLAGS (each fetch is for a range of message numbers). We don't yet use = CONDSTORE/QRESYNCH because the target server for the current release = doesn't support them. Regards Ben Ben Last=20 R & D Manager EMCC Software Ltd _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Mon Feb 26 06:42:08 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLeEe-0000xS-Ca; Mon, 26 Feb 2007 06:41:40 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLeEd-0000xF-C7 for lemonade@ietf.org; Mon, 26 Feb 2007 06:41:39 -0500 Received: from rufus.isode.com ([62.3.217.251]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HLeEc-0004hv-0L for lemonade@ietf.org; Mon, 26 Feb 2007 06:41:39 -0500 Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Mon, 26 Feb 2007 11:41:36 +0000 Message-ID: <45E042BA.8040608@isode.com> Date: Sat, 24 Feb 2007 13:50:50 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Eric Burger Subject: Re: [lemonade] Draft Agenda References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.3 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: "lemonade@ietf.org" X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Eric Burger wrote: >Monday >====== >Agenda Bashing (5 min) > >Quick Discussions: >Convert (10 min) >Deployments (10 min) > >Longer Discussions: >Quick Reconnect (20 min) > > I don't think we need that much time, as there are no open issues in the document and it is already past WGLC. >Notifications (60 min) > > Eric, do you want to expand on who is going to present this one. Are we talking about IMAP NOTIFY extension, notification format, etc? >Thursday >======== >Agenda Bashing (5 min) > >SMTP Restart (10 min) >IMAP Sieve (10 min) >Streaming (10 min) >Notifications Conclusion (20 min) >Profile-bis (20 min) >Marketing (10 min) >Views (60 min) >Updates & Next Steps (15 min) > > >We will cover document status not needing discussion on the list. This >includes: >Compress >IMAP URL >SASL-IR >Within > > The rest looks reasonable. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Mon Feb 26 15:07:28 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLm88-0003KD-Eg; Mon, 26 Feb 2007 15:07:28 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLm84-0003JQ-Rr; Mon, 26 Feb 2007 15:07:24 -0500 Received: from ns1.neustar.com ([2001:503:c779:1a::9c9a:108a]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HLm81-0006F7-T1; Mon, 26 Feb 2007 15:07:24 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns1.neustar.com (Postfix) with ESMTP id BB20026ED2; Mon, 26 Feb 2007 20:07:21 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1HLm81-0006ay-L4; Mon, 26 Feb 2007 15:07:21 -0500 X-test-idtracker: no To: IETF-Announce From: The IESG Message-Id: Date: Mon, 26 Feb 2007 15:07:21 -0500 X-Spam-Score: -2.8 (--) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: lemonade@ietf.org Subject: [lemonade] Last Call: draft-ietf-lemonade-search-within (WITHIN Search extension to the IMAP Protocol) to Proposed Standard X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ietf@ietf.org List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org The IESG has received a request from the Enhancements to Internet email to Support Diverse Service Environments WG (lemonade) to consider the following document: - 'WITHIN Search extension to the IMAP Protocol ' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2007-03-12. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-lemonade-search-within-03.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=14488&rfc_flag=0 _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Wed Feb 28 15:50:42 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMVkp-0008Bw-UW; Wed, 28 Feb 2007 15:50:28 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMVkT-0006zJ-FG; Wed, 28 Feb 2007 15:50:05 -0500 Received: from ns0.neustar.com ([156.154.16.158]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HMVkQ-0001dL-Kt; Wed, 28 Feb 2007 15:50:05 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id 7333832934; Wed, 28 Feb 2007 20:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1HMVkQ-0004uL-AL; Wed, 28 Feb 2007 15:50:02 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Wed, 28 Feb 2007 15:50:02 -0500 X-Spam-Score: -2.5 (--) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: lemonade@ietf.org Subject: [lemonade] I-D ACTION:draft-ietf-lemonade-reconnect-client-03.txt X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Enhancements to Internet email to Support Diverse Service Environments Working Group of the IETF. Title : IMAP4 Extensions for Quick Mailbox Resynchronization Author(s) : A. Melnikov, et al. Filename : draft-ietf-lemonade-reconnect-client-03.txt Pages : 25 Date : 2007-2-28 This document defines an IMAP4 extension, which gives an IMAP client the ability to quickly resynchronize any previously opened mailbox as part of the SELECT command, without the need for server-side state or additional client round-trips. This extension also introduces a new response that allows for a more compact representation for a list of expunged messages. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-lemonade-reconnect-client-03.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-lemonade-reconnect-client-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-lemonade-reconnect-client-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-2-28142441.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-lemonade-reconnect-client-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-lemonade-reconnect-client-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-2-28142441.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade --NextPart--