From lemonade-bounces@ietf.org Mon Jun 2 10:15:04 2008 Return-Path: X-Original-To: lemonade-archive@optimus.ietf.org Delivered-To: ietfarch-lemonade-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5620C28C12A; Mon, 2 Jun 2008 10:15:04 -0700 (PDT) X-Original-To: lemonade@ietf.org Delivered-To: lemonade@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id F17763A6960; Mon, 2 Jun 2008 10:15:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20080602171501.F17763A6960@core3.amsl.com> Date: Mon, 2 Jun 2008 10:15:01 -0700 (PDT) Cc: lemonade@ietf.org Subject: [lemonade] I-D Action:draft-ietf-lemonade-streaming-06.txt X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: lemonade-bounces@ietf.org 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 : Streaming Internet Messaging Attachments Author(s) : N. Cook Filename : draft-ietf-lemonade-streaming-06.txt Pages : 29 Date : 2008-06-02 This document describes a method for streaming multimedia attachments received by a resource constrained and/or mobile device from an IMAP server. It allows such clients, which often have limits in storage space and bandwidth, to play video and audio e-mail content. The document describes a profile for making use of the IMAP URLAUTH extension (RFC 4467), the Network Announcement SIP Media Service (RFC 4240), and the Media Server Control Markup Language (RFC 5022).Conventions Used in this Document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [KEYWORDS]. In examples, "C:" and "S:" indicate lines sent by the client and server respectively. If a single "C:" or "S:" label applies to multiple lines, then some of the line breaks between those lines are for editorial clarity only and may not be part of the actual protocol exchange. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-lemonade-streaming-06.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ 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: Message/External-body; name="draft-ietf-lemonade-streaming-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-06-02100608.I-D@ietf.org> --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://www.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade --NextPart-- From lemonade-bounces@ietf.org Tue Jun 3 07:37:51 2008 Return-Path: X-Original-To: lemonade-archive@optimus.ietf.org Delivered-To: ietfarch-lemonade-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4F1B03A68A7; Tue, 3 Jun 2008 07:37:51 -0700 (PDT) X-Original-To: lemonade@core3.amsl.com Delivered-To: lemonade@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4A9B13A6843 for ; Tue, 3 Jun 2008 07:37:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JRE+1YEKG6xn for ; Tue, 3 Jun 2008 07:37:46 -0700 (PDT) Received: from dovecot.org (dovecot.org [82.118.211.50]) by core3.amsl.com (Postfix) with ESMTP id 2255C3A6B27 for ; Tue, 3 Jun 2008 07:35:41 -0700 (PDT) Received: from [192.168.10.2] (xdsl-177-118.nblnetworks.fi [217.30.177.118]) by dovecot.org (Postfix) with ESMTP id 1D23116471E8 for ; Tue, 3 Jun 2008 17:35:10 +0300 (EEST) From: Timo Sirainen To: lemonade Date: Tue, 03 Jun 2008 17:35:09 +0300 Message-Id: <1212503709.3904.654.camel@hurina> Mime-Version: 1.0 X-Mailer: Evolution 2.22.1 Subject: [lemonade] CONTEXT X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0268404255==" Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org --===============0268404255== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-N0tRfYFXr0jD/RPSodjy" --=-N0tRfYFXr0jD/RPSodjy Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 1) If ADDTO refers to newly added messages, shouldn't it be required to be sent after EXISTS, just like REMOVETO must be sent before EXPUNGE? So an example session would look like: B01 SEARCH RETURN (UPDATE) ALL * ESEARCH (TAG "B01") 1 B01 OK .. * 1 EXPUNGE =EF=BB=BF* ESEARCH (TAG "B01") UID REMOVEFROM (0 1) * 1 EXISTS * ESEARCH (TAG "B01") UID ADDTO (0 1) 2) Is the context position really all that useful in ESEARCH replies? With sequence numbers they're completely useless and with UIDs I'd think it's better to optimize for bandwidth usage rather than for the tiny help in client's CPU usage. 3) ESORT description is somewhat ambiguous. > Servers advertising the capability "ESORT" support the return options > specified in [ESEARCH] Support where? Apparently in SORT command, but could be explicit. > These update sets are carried in ADDTO and REMOVEFROM data items in > ESEARCH/ESORT responses. What ESORT responses? Wasn't SORT also replying with ESEARCH replies? Would ESORT replies be better? If 2) gets changed, it would make it clearer that ADDTO/REMOVEFROM has the context position. Also the context position description could use several examples to make sure the implementors get it right. --=-N0tRfYFXr0jD/RPSodjy Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQBIRVadyUhSUUBViskRAvZkAJ9gOedkfwN/lWxJRWdcU8bMVbysVgCeOLUt s/rjfeZkFRCb0ma90iZTOD0= =oi4x -----END PGP SIGNATURE----- --=-N0tRfYFXr0jD/RPSodjy-- --===============0268404255== 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://www.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade --===============0268404255==-- From lemonade-bounces@ietf.org Tue Jun 3 09:58:56 2008 Return-Path: X-Original-To: lemonade-archive@optimus.ietf.org Delivered-To: ietfarch-lemonade-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A91B53A6AB3; Tue, 3 Jun 2008 09:58:56 -0700 (PDT) X-Original-To: lemonade@core3.amsl.com Delivered-To: lemonade@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 340133A69F3 for ; Tue, 3 Jun 2008 09:58:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QHWF6gUxL0cF for ; Tue, 3 Jun 2008 09:58:55 -0700 (PDT) Received: from dovecot.org (dovecot.org [82.118.211.50]) by core3.amsl.com (Postfix) with ESMTP id E123C28C1E3 for ; Tue, 3 Jun 2008 09:58:16 -0700 (PDT) Received: from [192.168.10.2] (xdsl-177-118.nblnetworks.fi [217.30.177.118]) by dovecot.org (Postfix) with ESMTP id 35FE616471E8 for ; Tue, 3 Jun 2008 19:57:49 +0300 (EEST) From: Timo Sirainen To: lemonade In-Reply-To: <1212503709.3904.654.camel@hurina> References: <1212503709.3904.654.camel@hurina> Date: Tue, 03 Jun 2008 19:57:48 +0300 Message-Id: <1212512268.3904.668.camel@hurina> Mime-Version: 1.0 X-Mailer: Evolution 2.22.1 Subject: Re: [lemonade] CONTEXT X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0032802375==" Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org --===============0032802375== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-6Z/sRFD+S0wxE6WNAyhc" --=-6Z/sRFD+S0wxE6WNAyhc Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Tue, 2008-06-03 at 17:35 +0300, Timo Sirainen wrote: > 2) Is the context position really all that useful in ESEARCH replies? > With sequence numbers they're completely useless and with UIDs I'd think > it's better to optimize for bandwidth usage rather than for the tiny > help in client's CPU usage. How about making the context positions completely optional, even for SORT? I was just thinking that my virtual mailbox implementation should probably do the initial build by sorting matching messages by INTERNALDATE, but all newly seen messages would be added to end of the mailbox. So I would want to use SORT RETURN (UPDATE), but I wouldn't want to see context positions. So something like: SORT RETURN (UPDATE POSITIONS) ..=20 But since they're pointless for SEARCH sequences (but not UID SEARCH): SEARCH RETURN (UPDATE POSITIONS) .. BAD If POSITIONS is specified, the server MUST return them correctly. Special casing position 0 could be removed then. --=-6Z/sRFD+S0wxE6WNAyhc Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQBIRXgMyUhSUUBViskRAgUCAJ9IbwamU/B7jex2FUZMXP9wxamW2gCeIGGO uSDV1lMhYpfpXm2hSpYQq5E= =6/ox -----END PGP SIGNATURE----- --=-6Z/sRFD+S0wxE6WNAyhc-- --===============0032802375== 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://www.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade --===============0032802375==-- From lemonade-bounces@ietf.org Tue Jun 3 10:35:25 2008 Return-Path: X-Original-To: lemonade-archive@optimus.ietf.org Delivered-To: ietfarch-lemonade-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BFD133A6B9E; Tue, 3 Jun 2008 10:35:25 -0700 (PDT) X-Original-To: lemonade@core3.amsl.com Delivered-To: lemonade@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6BAE428C1F0 for ; Tue, 3 Jun 2008 10:35:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id raMgxi1wBXy9 for ; Tue, 3 Jun 2008 10:35:22 -0700 (PDT) Received: from turner.dave.cridland.net (unknown [IPv6:2001:838:378:0:211:9ff:fe2c:e28e]) by core3.amsl.com (Postfix) with ESMTP id 516833A6BAF for ; Tue, 3 Jun 2008 10:31:20 -0700 (PDT) Received: from peirce.dave.cridland.net ([217.155.137.61]) by turner.dave.cridland.net (submission) via TCP with ESMTPA id for ; Tue, 3 Jun 2008 18:31:04 +0100 References: <1212503709.3904.654.camel@hurina> In-Reply-To: <1212503709.3904.654.camel@hurina> MIME-Version: 1.0 Message-Id: <1695.1212514262.389177@peirce.dave.cridland.net> Date: Tue, 03 Jun 2008 18:31:02 +0100 From: Dave Cridland To: Enhancements to Internet email to support diverse service enivronments X-Encoded: Changed encoding from 8Bit for 7bit transmission Subject: Re: [lemonade] CONTEXT X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org T24gVHVlIEp1biAgMyAxNTozNTowOSAyMDA4LCBUaW1vIFNpcmFpbmVuIHdyb3RlOgo+IDEpIElm IEFERFRPIHJlZmVycyB0byBuZXdseSBhZGRlZCBtZXNzYWdlcywgc2hvdWxkbid0IGl0IGJlICAg Cj4gcmVxdWlyZWQgdG8KPiBiZSBzZW50IGFmdGVyIEVYSVNUUywganVzdCBsaWtlIFJFTU9WRVRP IG11c3QgYmUgc2VudCBiZWZvcmUgICAKPiBFWFBVTkdFPyBTbwo+IGFuIGV4YW1wbGUgc2Vzc2lv biB3b3VsZCBsb29rIGxpa2U6Cj4gCj4gQjAxIFNFQVJDSCBSRVRVUk4gKFVQREFURSkgQUxMCj4g KiBFU0VBUkNIIChUQUcgIkIwMSIpIDEKPiBCMDEgT0sKPiAuLgo+ICogMSBFWFBVTkdFCj4g77u/ KiBFU0VBUkNIIChUQUcgIkIwMSIpIFVJRCBSRU1PVkVGUk9NICgwIDEpCj4gKiAxIEVYSVNUUwo+ ICogRVNFQVJDSCAoVEFHICJCMDEiKSBVSUQgQUREVE8gKDAgMSkKPiAKPiAKUkVNT1ZFRlJPTSBv bmx5IG5lZWRzIHRvIGJlIHNlbnQgcHJpb3IgdG8gRVhQVU5HRSBpZiBpdCByZWZlcnMgdG8gICAK TVNOcywgc2luY2Ugb3RoZXJ3aXNlIGl0IGlzIGltcG9zc2libGUgdG8gcmVmZXJlbmNlIHRoZSBt ZXNzYWdlIHRvIGJlICAKICByZW1vdmVkIGZyb20gdGhlIGNvbnRleHQgLSBpdCdzIG5vdCBhIG1h dHRlciBvZiBldmVudCBvcmRlcmluZywgIApib3RoICB0aGUgUkVNT1ZFRlJPTSBhbmQgRVhQVU5H RSBvY2N1ciBzaW11bHRhbmVvdXNseSBieSBkZWZpbml0aW9uIC0gIAppdCdzICBhIG1hdHRlciBv ZiB3aGVuIHRoZXkgY2FuIGJlIHJlcG9ydGVkLgoKCj4gMikgSXMgdGhlIGNvbnRleHQgcG9zaXRp b24gcmVhbGx5IGFsbCB0aGF0IHVzZWZ1bCBpbiBFU0VBUkNIICAgCj4gcmVwbGllcz8KPiBXaXRo IHNlcXVlbmNlIG51bWJlcnMgdGhleSdyZSBjb21wbGV0ZWx5IHVzZWxlc3MgYW5kIHdpdGggVUlE cyBJJ2QgICAKPiB0aGluawo+IGl0J3MgYmV0dGVyIHRvIG9wdGltaXplIGZvciBiYW5kd2lkdGgg dXNhZ2UgcmF0aGVyIHRoYW4gZm9yIHRoZSB0aW55Cj4gaGVscCBpbiBjbGllbnQncyBDUFUgdXNh Z2UuCj4gCj4gCk5vLCB0aGV5IGhhdmUgbG93IHV0aWxpdHkgaW4gYm90aCBTRUFSQ0ggYW5kIFVJ RCBTRUFSQ0guIEJ5ICJsb3cgICAKdXRpbGl0eSIsIEkgbWVhbiBtYXJnaW5hbGx5IG1vcmUgdXNl ZnVsIHRoYW4gbWFyZ2luYWwgdXRpbGl0eSAtIEkgICAKd291bGRuJ3QgZ2V0IHRvbyBleGljaXRl ZCBieSB0aGVtLgoKVGhlIGJ1bGsgb2YgdGhlIHV0aWxpdHkgaXMgaW4gZmlndXJpbmcgb3V0IHdo ZXJlLCBpbiB0aGUgY29udGV4dCwgdGhlICAKICByZXN1bHRzIHlvdSBoYXZlIGFyZSwgZ2l2ZW4g dGhlIGNoYW5nZS4gRm9yIHJlc3VsdHMgeW91IGhhZCBiZWZvcmUgICAKdGhlIGNoYW5nZSwgdGhp cyBpcyBhbHdheXMgcG9zc2libGUgZm9yIGEgU0VBUkNILWRlcml2ZWQgY29udGV4dCwgICAKd2hl cmVhcyBmb3IgdGhlIHJlc3VsdHMgeW91IGdldCBpbiBhbiBBRERUTywgdGhlIGNvbnRleHQgcG9z aXRpb24gY2FuICAKICB0ZWxsIHlvdS4gKE9yIGluIHNvbWUgY2FzZXMgeW91IGNhbiBsb2dpY2Fs bHkgZGV0ZXJtaW5lIHdoZXJlIHRoZSAgIApyZXN1bHRzIGxpZSkuCgpJdCdzIG5ldmVyIG5lZWRl ZCBieSBjbGllbnRzIGZvciBSRU1PVkVGUk9NLCBidXQgSSBwZXJzb25hbGx5IHN1c3BlY3QgIAog IHRoYXQgZ2l2ZW4gYXZhaWxhYmlsaXR5IG9mIEVTT1JULCBjbGllbnQgaW1wbGVtZW50b3JzIHdv dWxkICAKZ2VuZXJhbGx5ICBiZSB1c2luZyBpdC4KCgo+IDMpIEVTT1JUIGRlc2NyaXB0aW9uIGlz IHNvbWV3aGF0IGFtYmlndW91cy4KPiAKPiA+IFNlcnZlcnMgYWR2ZXJ0aXNpbmcgdGhlIGNhcGFi aWxpdHkgIkVTT1JUIiBzdXBwb3J0IHRoZSByZXR1cm4gICAKPiBvcHRpb25zCj4gPiAgICBzcGVj aWZpZWQgaW4gW0VTRUFSQ0hdCj4gCj4gU3VwcG9ydCB3aGVyZT8gQXBwYXJlbnRseSBpbiBTT1JU IGNvbW1hbmQsIGJ1dCBjb3VsZCBiZSBleHBsaWNpdC4KPiAKPiAKQWdyZWVkLCBJIGNhbiBjaGFu Z2UgdGhhdCBpbiBBVVRINDguCgoKPiA+IFRoZXNlIHVwZGF0ZSBzZXRzIGFyZSBjYXJyaWVkIGlu IEFERFRPIGFuZCBSRU1PVkVGUk9NIGRhdGEgaXRlbXMgICAKPiBpbgo+ID4gICAgRVNFQVJDSC9F U09SVCByZXNwb25zZXMuCj4gCj4gV2hhdCBFU09SVCByZXNwb25zZXM/IFdhc24ndCBTT1JUIGFs c28gcmVwbHlpbmcgd2l0aCBFU0VBUkNIICAgCj4gcmVwbGllcz8KPiBXb3VsZCBFU09SVCByZXBs aWVzIGJlIGJldHRlcj8KCk9vb3BzLiBUaGFua3MgZm9yIHNwb3R0aW5nIHRoYXQuIFllcywgdGhl IGV4dGVuZGVkIFNPUlQgcmVwbGllcyB3aXRoICAgCkVTRUFSQ0ggcmVzcG9uc2VzLCBzaW5jZSB0 aGUgdHdvIHR1cm5lZCBvdXQgdG8gYmUgc2VtYW50aWNhbGx5ICAgCmVxdWl2YWxlbnQsIGFuZCBk aXN0aW5ndWlzaGFibGUuIChNdWNoIGxpa2UgQUNBUCBoYXMgb25seSBTRUFSQ0gsICAgCndoaWNo IGNhbiBvcHRpb25hbGx5IFNPUlQpLgoKSW4gZmFjdCwgaW4gSU1BUCwgd2UgZGVjbGFyZSB0aGF0 IGV2ZW4gYSBTRUFSQ0ggaXMgYWN0dWFsbHkganVzdCBhICAgClNPUlQtYnktVUlELgoKPiAgSWYg MikgZ2V0cyBjaGFuZ2VkLCBpdCB3b3VsZCBtYWtlIGl0Cj4gY2xlYXJlciB0aGF0IEFERFRPL1JF TU9WRUZST00gaGFzIHRoZSBjb250ZXh0IHBvc2l0aW9uLgo+IAo+IEFsc28gdGhlIGNvbnRleHQg cG9zaXRpb24gZGVzY3JpcHRpb24gY291bGQgdXNlIHNldmVyYWwgZXhhbXBsZXMgdG8gIAo+ICBt YWtlCj4gc3VyZSB0aGUgaW1wbGVtZW50b3JzIGdldCBpdCByaWdodC4KClBvc3NpYmx5LCBidXQg dGhpcyBtaWdodCBiZSBnb2luZyBiZXlvbmQgd2hhdCBJIGNhbiBzYWZlbHkgZG8gaW4gICAKQVVU SDQ4IC0gaG93ZXZlciwgYXMgaXQncyBub3QgeWV0IGdvbmUgdGhyb3VnaCB0aGUgSUVTRyB0ZWxl Y2hhdCwgICAKSSdsbCBhc2sgQ2hyaXMuIEknZCBub3RlIHRoYXQgSSdtIHVubGlrZWx5IHRvIGlu dHJvZHVjZSBuZXcgZXhhbXBsZXMgICAKdW5sZXNzIHRoZXkncmUgbW9yZSBvciBsZXNzIHdyaXR0 ZW4gZm9yIG1lIGFuZCBwb3N0ZWQgdG8gdGhlIGxpc3QgZm9yICAKICBwZW9wbGUgdG8gY2hlY2su CgpEYXZlLgotLSAKRGF2ZSBDcmlkbGFuZCAtIG1haWx0bzpkYXZlQGNyaWRsYW5kLm5ldCAtIHht cHA6ZHdkQGRhdmUuY3JpZGxhbmQubmV0CiAgLSBhY2FwOi8vYWNhcC5kYXZlLmNyaWRsYW5kLm5l dC9ieW93bmVyL3VzZXIvZHdkL2Jvb2ttYXJrcy8KICAtIGh0dHA6Ly9kYXZlLmNyaWRsYW5kLm5l dC8KSW5mb3Ryb3BlIFBvbHltZXIgLSBBQ0FQLCBJTUFQLCBFU01UUCwgYW5kIExlbW9uYWRlCl9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCmxlbW9uYWRlIG1h aWxpbmcgbGlzdApsZW1vbmFkZUBpZXRmLm9yZwpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL2xlbW9uYWRlClN1cHBsZW1lbnRhbCBXZWIgU2l0ZToKaHR0cDovL3d3dy5zdGFu ZGFyZHN0cmFjay5jb20vaWV0Zi9sZW1vbmFkZQ== From lemonade-bounces@ietf.org Tue Jun 3 10:35:26 2008 Return-Path: X-Original-To: lemonade-archive@optimus.ietf.org Delivered-To: ietfarch-lemonade-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5359228C1A1; Tue, 3 Jun 2008 10:35:26 -0700 (PDT) X-Original-To: lemonade@core3.amsl.com Delivered-To: lemonade@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8C57D3A6B8C for ; Tue, 3 Jun 2008 10:35:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PoLoAgPkh0F8 for ; Tue, 3 Jun 2008 10:35:22 -0700 (PDT) Received: from turner.dave.cridland.net (unknown [IPv6:2001:838:378:0:211:9ff:fe2c:e28e]) by core3.amsl.com (Postfix) with ESMTP id 549353A6BC1 for ; Tue, 3 Jun 2008 10:31:49 -0700 (PDT) Received: from peirce.dave.cridland.net ([217.155.137.61]) by turner.dave.cridland.net (submission) via TCP with ESMTPA id for ; Tue, 3 Jun 2008 18:31:31 +0100 X-SMTP-Protocol-Errors: PIPELINING References: <1212503709.3904.654.camel@hurina> <1212512268.3904.668.camel@hurina> In-Reply-To: <1212512268.3904.668.camel@hurina> MIME-Version: 1.0 Message-Id: <1695.1212514290.947745@peirce.dave.cridland.net> Date: Tue, 03 Jun 2008 18:31:30 +0100 From: Dave Cridland To: Enhancements to Internet email to support diverse service enivronments Subject: Re: [lemonade] CONTEXT X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org On Tue Jun 3 17:57:48 2008, Timo Sirainen wrote: > On Tue, 2008-06-03 at 17:35 +0300, Timo Sirainen wrote: > > 2) Is the context position really all that useful in ESEARCH > replies? > > With sequence numbers they're completely useless and with UIDs > I'd think > > it's better to optimize for bandwidth usage rather than for the > tiny > > help in client's CPU usage. > > How about making the context positions completely optional, even for > SORT? I was just thinking that my virtual mailbox implementation > should > probably do the initial build by sorting matching messages by > INTERNALDATE, but all newly seen messages would be added to end of > the > mailbox. So I would want to use SORT RETURN (UPDATE), but I wouldn't > want to see context positions. > > You're talking about a client, here, or the server? If you're describing client behaviour, the problem is that you're going to have to obtain a full result set initially, otherwise you'll have no idea "where" the results are that you need to remove. > So something like: > > SORT RETURN (UPDATE POSITIONS) .. > > But since they're pointless for SEARCH sequences (but not UID > SEARCH): > > Ah, no, they're just less useful, because of what the natural sort order is. SEARCH is not unordered with CONTEXT. The reason it's always present, but optional for servers in the case of SEARCH, is that it's just a "nice to have" for clients requesting SEARCH, whereas it can be quite painful to implement for servers, so it's nice to leave it optional. Dave. -- Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@dave.cridland.net - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade _______________________________________________ lemonade mailing list lemonade@ietf.org https://www.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Tue Jun 3 20:11:59 2008 Return-Path: X-Original-To: lemonade-archive@optimus.ietf.org Delivered-To: ietfarch-lemonade-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 48F5D3A6AA7; Tue, 3 Jun 2008 20:11:59 -0700 (PDT) X-Original-To: lemonade@core3.amsl.com Delivered-To: lemonade@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A39893A6AA3 for ; Tue, 3 Jun 2008 20:11:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZcVBijwxlq3o for ; Tue, 3 Jun 2008 20:11:56 -0700 (PDT) Received: from mta02.zimbra.com (mta02.zimbra.com [77.67.121.28]) by core3.amsl.com (Postfix) with ESMTP id EB9D93A6913 for ; Tue, 3 Jun 2008 20:11:56 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mta02.zimbra.com (Postfix) with ESMTP id 934F3C7832E; Tue, 3 Jun 2008 20:11:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at Received: from mta02.zimbra.com ([127.0.0.1]) by localhost (mta02.zimbra.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OYo6bsianOgk; Tue, 3 Jun 2008 20:11:54 -0700 (PDT) Received: from dogfood.zimbra.com (dogfood.zimbra.com [10.10.140.44]) by mta02.zimbra.com (Postfix) with ESMTP id 45C7AC78251; Tue, 3 Jun 2008 20:11:54 -0700 (PDT) Date: Tue, 3 Jun 2008 20:11:59 -0700 (PDT) From: Dan Karp To: IMAP Extensions WG , Enhancements to Internet email to support diverse service enivronments Message-ID: <913883255.3241212549118973.JavaMail.root@dogfood.zimbra.com> MIME-Version: 1.0 X-Mailer: Zimbra 5.0.7_GA_2351.RHEL4_64 (ZimbraWebClient - FF2.0 (Win)/5.0.7_GA_2351.RHEL4_64) Subject: [lemonade] SORT and CONDSTORE X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org Quick question: Should A001 SORT (DATE) UTF-8 MODSEQ 500 cause a " (MODSEQ 4551)" to be appended to the SORT result? The SORT extension doesn't indicate it, but it seems as necessary as adding it to the corresponding SEARCH. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Wed Jun 4 03:28:27 2008 Return-Path: X-Original-To: lemonade-archive@optimus.ietf.org Delivered-To: ietfarch-lemonade-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 000E83A6C6C; Wed, 4 Jun 2008 03:28:26 -0700 (PDT) X-Original-To: lemonade@core3.amsl.com Delivered-To: lemonade@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 417673A6C5A for ; Wed, 4 Jun 2008 03:28:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.103 X-Spam-Level: X-Spam-Status: No, score=-2.103 tagged_above=-999 required=5 tests=[AWL=0.496, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZwCWcZ3mCdhZ for ; Wed, 4 Jun 2008 03:28:24 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id 9151C3A6C65 for ; Wed, 4 Jun 2008 03:24:47 -0700 (PDT) Received: from [172.16.2.192] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Wed, 4 Jun 2008 11:24:50 +0100 Message-ID: <484657A5.5070202@isode.com> Date: Wed, 04 Jun 2008 09:51:49 +0100 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: Timo Sirainen References: <8B9B8F32-8DEF-40B9-992E-9337FB7AE344@standardstrack.com> <1210951366.9518.654.camel@hurina> <48312F7D.8090103@isode.com> <1211191304.9518.755.camel@hurina> <4835D000.4080808@isode.com> <1211745339.3904.166.camel@hurina> <483BAB35.2080806@isode.com> <1B7D968F-7A77-40FC-AFD6-ADF3C2826822@iki.fi> In-Reply-To: <1B7D968F-7A77-40FC-AFD6-ADF3C2826822@iki.fi> MIME-Version: 1.0 Cc: lemonade Subject: Re: [lemonade] WGLC NOTIFY X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org Hi Timo, Timo Sirainen wrote: > On May 27, 2008, at 9:33 AM, Alexey Melnikov wrote: > >> Timo Sirainen wrote: >> >>> One more thing I thought of: >>> >>>> If IDLE (as well as this extension) is supported, while processing >>>> IDLE the server MUST send the same events as instructed by the >>>> client using the NOTIFY command. >>> >>> Does this mean EXPUNGEs must not be sent if MessageExpunge isn't >>> included in NOTIFY SET? >> >> Correct. >> >>> That would make it impossible to create clients >>> that use MSNs and want to be immediately notified of EXPUNGEs (while >>> IDLEing). >> >> Correct. The client can either chose not to use NOTIFY at all (in which >> case it will get expunges with MSNs), or it can chose to specify both >> MessageNew & MessageExpunge (they are tied together as per section 5), >> in which case it will get back UIDs. > This statement was incorrect (and I think your statement on which I commented is also incorrect). When MessageExpunge is requested, the server will either send EXPUNGE (with message numbers) or VANISHED (with UIDs). VANISHED is only sent if QRESYNC was also enabled. Having said that, if the client specifies MessageExpunge and QRESYNC was not enabled, it will get MSNs immediately. > "get back UIDs"? Do you mean VANISHED? Doesn't that depend on the > server if it or EXPUNGE is sent? > > What happens if NOTIFY SET is used, but SELECTED isn't specified? I > can't seem to find this from the draft. I'm guessing it'll use the > defaults? Or does it use the first other matching rule? Good question. I think this needs to be clarified. > Anyway I think this is too restrictive if using NOTIFY basically > requires the client to drop using MSNs. After rereading some portions of draft-ietf-lemonade-imap-notify, I would like to correct this: a client using NOTIFY can't use MSNs in commands it is issuing. However it will still be using MSNs to process server responses. > Some use cases for clients which want to keep using MSNs and IDLE: > > 1. Client just wants to use NOTIFY to see changes in other mailboxes, > so it specifies NOTIFY SET (personal (messagenew messageexpunge)). I assume the client still wants to immediately see changes in the current mailbox? In this case it should also include (selected (MessageNew MessageExpunge)) and things should work as before. > 2. Client wants to use NOTIFY to ignore annotation changes, so it uses > NOTIFY SET (selected (FlagChange)). FlagChange is tied to MessageNew and MessageExpunge, so this should really be "NOTIFY SET (selected (FlagChange MessageNew MessageExpunge))" > EXISTS and EXPUNGEs are still sent in command replies, but not during > IDLE? They will be sent in IDLE as well, as per my previous comment. > 3. Client wants to get pushed information about new messages' contents > (MessageNew (uid ..)), but it still wants to keep using MSNs. Can you elaborate on this use case? Your MessageNew already contains "uid", so clearly the client is already capable of using UIDs anyway. > Since MessageNew and MessageExpunge must specified together, this is > impossible . > > Is there even any other reason for client to even run IDLE unless it > wants to keep using MSNs + see EXPUNGEs immediately? I think IDLE > could be specified as sending EXPUNGEs immediately regardless of > whether MessagExpunge has been specified. I would rather not special case IDLE, so that we can keep server logic consistent. In light of my corrected statement above, can you double check that there is any issue? > 3. is also problematic. Is it really necessary to give MessageExpunge > if MessageNew is given? The (well-behaving) servers already have to > handle the case when a message is expunged and a new message arrives > during FETCH/STORE/SEARCH command. The client is notified about the > new message but not about the expunge. True. The reason why we have MessageExpunge and MessageNew tied together is because representative of a certain company kept moaning that he can't implement them separately. The WG couldn't find any use cases where this would make a difference for a client. >> It is possible that some servers that support IDLE don't send >> MessageExpunge events while idling, but I haven't seen any such server. >> We could mandate that all servers advertising the NOTIFY capability send >> MessageExpunge during IDLE if NOTIFY wasn't issued on the connection?! > > I don't think that really matters since well-behaving servers already > do that. I'm more concerned that well-behaving servers aren't allowed > to do that when NOTIFY is used.. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Wed Jun 4 06:36:12 2008 Return-Path: X-Original-To: lemonade-archive@optimus.ietf.org Delivered-To: ietfarch-lemonade-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9257428C113; Wed, 4 Jun 2008 06:36:12 -0700 (PDT) X-Original-To: lemonade@core3.amsl.com Delivered-To: lemonade@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1DBAE28C113 for ; Wed, 4 Jun 2008 06:36:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.434 X-Spam-Level: X-Spam-Status: No, score=-2.434 tagged_above=-999 required=5 tests=[AWL=0.165, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DHfycdIsHRUj for ; Wed, 4 Jun 2008 06:36:05 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id 9C16E28C10A for ; Wed, 4 Jun 2008 06:36:05 -0700 (PDT) Received: from [172.16.2.192] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Wed, 4 Jun 2008 14:36:09 +0100 Message-ID: <48469A35.2030407@isode.com> Date: Wed, 04 Jun 2008 14:35:49 +0100 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: Dan Karp References: <913883255.3241212549118973.JavaMail.root@dogfood.zimbra.com> In-Reply-To: <913883255.3241212549118973.JavaMail.root@dogfood.zimbra.com> MIME-Version: 1.0 Cc: IMAP Extensions WG , Enhancements to Internet email to support diverse service enivronments Subject: Re: [lemonade] SORT and CONDSTORE X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org Dan Karp wrote: >Quick question: Should > > A001 SORT (DATE) UTF-8 MODSEQ 500 > >cause a " (MODSEQ 4551)" to be appended to the SORT result? The >SORT extension doesn't indicate it, but it seems as necessary as >adding it to the corresponding SEARCH. > > I agree. I can include this into QRESYNC RFC update. (I wish we could use ESEARCH response in all cases.) _______________________________________________ lemonade mailing list lemonade@ietf.org https://www.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Wed Jun 4 07:46:25 2008 Return-Path: X-Original-To: lemonade-archive@optimus.ietf.org Delivered-To: ietfarch-lemonade-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 178EC3A6936; Wed, 4 Jun 2008 07:46:25 -0700 (PDT) X-Original-To: lemonade@core3.amsl.com Delivered-To: lemonade@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A979F3A688A for ; Wed, 4 Jun 2008 07:46:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FsK42K72QbgS for ; Wed, 4 Jun 2008 07:46:19 -0700 (PDT) Received: from mta02.zimbra.com (mta02.zimbra.com [77.67.121.28]) by core3.amsl.com (Postfix) with ESMTP id 602B23A68F0 for ; Wed, 4 Jun 2008 07:46:19 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mta02.zimbra.com (Postfix) with ESMTP id EA35DC7826F; Wed, 4 Jun 2008 07:46:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at Received: from mta02.zimbra.com ([127.0.0.1]) by localhost (mta02.zimbra.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QtliAUBTvqQI; Wed, 4 Jun 2008 07:46:17 -0700 (PDT) Received: from dogfood.zimbra.com (dogfood.zimbra.com [10.10.140.44]) by mta02.zimbra.com (Postfix) with ESMTP id A6916C7825C; Wed, 4 Jun 2008 07:46:17 -0700 (PDT) Date: Wed, 4 Jun 2008 07:46:21 -0700 (PDT) From: Dan Karp To: Alexey Melnikov Message-ID: <219134070.25531212590781760.JavaMail.root@dogfood.zimbra.com> In-Reply-To: <48469A35.2030407@isode.com> MIME-Version: 1.0 X-Mailer: Zimbra 5.0.7_GA_2351.RHEL4_64 (ZimbraWebClient - FF2.0 (Win)/5.0.7_GA_2351.RHEL4_64) Cc: IMAP Extensions WG , Enhancements to Internet email to support diverse service enivronments Subject: Re: [lemonade] SORT and CONDSTORE X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org > >Quick question: Should > > > > A001 SORT (DATE) UTF-8 MODSEQ 500 > > > >cause a " (MODSEQ 4551)" to be appended to the SORT result? The > >SORT extension doesn't indicate it, but it seems as necessary as > >adding it to the corresponding SEARCH. > > I agree. I can include this into QRESYNC RFC update. > (I wish we could use ESEARCH response in all cases.) Such a command should also be regarded as a CONDSTORE-enabling command. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Wed Jun 4 09:02:08 2008 Return-Path: X-Original-To: lemonade-archive@optimus.ietf.org Delivered-To: ietfarch-lemonade-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AD9403A6CC2; Wed, 4 Jun 2008 09:02:06 -0700 (PDT) X-Original-To: lemonade@core3.amsl.com Delivered-To: lemonade@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0E12C3A6CB5 for ; Wed, 4 Jun 2008 09:02:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.901 X-Spam-Level: X-Spam-Status: No, score=-5.901 tagged_above=-999 required=5 tests=[AWL=-0.698, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FEQ7kujiNqgR for ; Wed, 4 Jun 2008 09:01:51 -0700 (PDT) Received: from dovecot.org (dovecot.org [82.118.211.50]) by core3.amsl.com (Postfix) with ESMTP id C37803A6CA9 for ; Wed, 4 Jun 2008 09:01:48 -0700 (PDT) Received: from [192.168.10.2] (xdsl-177-118.nblnetworks.fi [217.30.177.118]) by dovecot.org (Postfix) with ESMTP id B8774FA8AF6; Wed, 4 Jun 2008 19:01:19 +0300 (EEST) From: Timo Sirainen To: Alexey Melnikov In-Reply-To: <484657A5.5070202@isode.com> References: <8B9B8F32-8DEF-40B9-992E-9337FB7AE344@standardstrack.com> <1210951366.9518.654.camel@hurina> <48312F7D.8090103@isode.com> <1211191304.9518.755.camel@hurina> <4835D000.4080808@isode.com> <1211745339.3904.166.camel@hurina> <483BAB35.2080806@isode.com> <1B7D968F-7A77-40FC-AFD6-ADF3C2826822@iki.fi> <484657A5.5070202@isode.com> Date: Wed, 04 Jun 2008 19:01:18 +0300 Message-Id: <1212595278.3904.735.camel@hurina> Mime-Version: 1.0 X-Mailer: Evolution 2.22.1 Cc: lemonade Subject: Re: [lemonade] WGLC NOTIFY X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1083108570==" Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org --===============1083108570== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-yTI5/2tuZswn/Yr2lFHJ" --=-yTI5/2tuZswn/Yr2lFHJ Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Wed, 2008-06-04 at 09:51 +0100, Alexey Melnikov wrote: > > Anyway I think this is too restrictive if using NOTIFY basically=20 > > requires the client to drop using MSNs. >=20 > After rereading some portions of draft-ietf-lemonade-imap-notify, I=20 > would like to correct this: a client using NOTIFY can't use MSNs in=20 > commands it is issuing. However it will still be using MSNs to process=20 > server responses. I'd hate to see that happen. It took me a while to understand that MSNs can be useful and I don't want to support an extension that forces clients to stop sending them in commands. Also many existing clients could benefit a lot from NOTIFY, since their "STATUS each mailbox every n minutes" could be replaced by a single NOTIFY command. But if this same command requires rewriting their command sending to use only UIDs, that could be a much larger job. > > Some use cases for clients which want to keep using MSNs and IDLE: > > > > 1. Client just wants to use NOTIFY to see changes in other mailboxes,=20 > > so it specifies NOTIFY SET (personal (messagenew messageexpunge)). >=20 > I assume the client still wants to immediately see changes in the=20 > current mailbox? In this case it should also include (selected=20 > (MessageNew MessageExpunge)) and things should work as before. Not if it can't send MSNs in commands. > > 2. Client wants to use NOTIFY to ignore annotation changes, so it uses=20 > > NOTIFY SET (selected (FlagChange)). >=20 > FlagChange is tied to MessageNew and MessageExpunge, so this should=20 > really be "NOTIFY SET (selected (FlagChange MessageNew MessageExpunge))" And again it couldn't send MSNs in commands. > > 3. Client wants to get pushed information about new messages' contents=20 > > (MessageNew (uid ..)), but it still wants to keep using MSNs. >=20 > Can you elaborate on this use case? > Your MessageNew already contains "uid", so clearly the client is already=20 > capable of using UIDs anyway. That was just an example. The fields could have been anything. But anyway just because it uses UIDs in some places doesn't mean it even could use UIDs everywhere. The best example is a Pine/webmail-like application that fetches information only about the visible part of the mailbox (in message list view). Those are the only kinds of IMAP clients that are able to access huge mailboxes efficiently. In them when a user scrolls a pageful up in message list, the client calculates how many messages it needs to fetch and uses a FETCH with a sequence range. This is impossible to do with UIDs unless the client fetches all UIDs, which in turn makes it inefficient (especially with huge mailboxes) and waste bandwidth for no good reason. > > Since MessageNew and MessageExpunge must specified together, this is=20 > > impossible . > > > > Is there even any other reason for client to even run IDLE unless it=20 > > wants to keep using MSNs + see EXPUNGEs immediately? I think IDLE=20 > > could be specified as sending EXPUNGEs immediately regardless of=20 > > whether MessagExpunge has been specified. >=20 > I would rather not special case IDLE, so that we can keep server logic=20 > consistent. > In light of my corrected statement above, can you double check that=20 > there is any issue? If special casing IDLE made client able to send MSNs, I think it would be useful to change it. But that also requires decoupling MessageExpunge from other events. > > 3. is also problematic. Is it really necessary to give MessageExpunge=20 > > if MessageNew is given? The (well-behaving) servers already have to=20 > > handle the case when a message is expunged and a new message arrives=20 > > during FETCH/STORE/SEARCH command. The client is notified about the=20 > > new message but not about the expunge. >=20 > True. > The reason why we have MessageExpunge and MessageNew tied together is=20 > because representative of a certain company kept moaning that he can't=20 > implement them separately. The WG couldn't find any use cases where this=20 > would make a difference for a client. Again it makes sending MSNs impossible, which is bad. I'd like it if all existing clients (which may be sending MSNs) could easily replace their STATUS-polling with a single notify command: 1 NOTIFY SET (selected (MessageNew FlagChange) personal (MessageNew Message= Expunge)) --=-yTI5/2tuZswn/Yr2lFHJ Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQBIRrxOyUhSUUBViskRAkjwAJ9GX0hotkMc6bp4GJzY6dw5B+QGpACeIlBl XV2WjBSS2Q0RAs970RDSnBs= =iw2I -----END PGP SIGNATURE----- --=-yTI5/2tuZswn/Yr2lFHJ-- --===============1083108570== 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://www.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade --===============1083108570==-- From lemonade-bounces@ietf.org Wed Jun 4 09:13:13 2008 Return-Path: X-Original-To: lemonade-archive@optimus.ietf.org Delivered-To: ietfarch-lemonade-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0156F28C18F; Wed, 4 Jun 2008 09:13:13 -0700 (PDT) X-Original-To: lemonade@core3.amsl.com Delivered-To: lemonade@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2A97828C18F for ; Wed, 4 Jun 2008 09:13:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.425 X-Spam-Level: X-Spam-Status: No, score=-6.425 tagged_above=-999 required=5 tests=[AWL=0.175, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t3AlVS-SxU4r for ; Wed, 4 Jun 2008 09:13:10 -0700 (PDT) Received: from dovecot.org (dovecot.org [82.118.211.50]) by core3.amsl.com (Postfix) with ESMTP id C3CE428C15E for ; Wed, 4 Jun 2008 09:13:09 -0700 (PDT) Received: from [192.168.10.2] (xdsl-177-118.nblnetworks.fi [217.30.177.118]) by dovecot.org (Postfix) with ESMTP id 5819C16474EF; Wed, 4 Jun 2008 19:12:43 +0300 (EEST) From: Timo Sirainen To: Alexey Melnikov In-Reply-To: <48469A35.2030407@isode.com> References: <913883255.3241212549118973.JavaMail.root@dogfood.zimbra.com> <48469A35.2030407@isode.com> Date: Wed, 04 Jun 2008 19:12:42 +0300 Message-Id: <1212595962.3904.737.camel@hurina> Mime-Version: 1.0 X-Mailer: Evolution 2.22.1 Cc: IMAP Extensions WG , Enhancements to Internet email to support diverse service enivronments Subject: Re: [lemonade] SORT and CONDSTORE X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1533397931==" Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org --===============1533397931== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-KQ3zD7tin5mww1uhb+fc" --=-KQ3zD7tin5mww1uhb+fc Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Wed, 2008-06-04 at 14:35 +0100, Alexey Melnikov wrote: > Dan Karp wrote: >=20 > >Quick question: Should > > > > A001 SORT (DATE) UTF-8 MODSEQ 500 > > > >cause a " (MODSEQ 4551)" to be appended to the SORT result? The > >SORT extension doesn't indicate it, but it seems as necessary as > >adding it to the corresponding SEARCH. > > =20 > > > I agree. I can include this into QRESYNC RFC update. > (I wish we could use ESEARCH response in all cases.) And what about THREAD? --=-KQ3zD7tin5mww1uhb+fc Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQBIRr76yUhSUUBViskRAujfAJ4widUJhevoaSjdDCgHpSP8BVsIPACeJgfF ABTeUIC+O7cIHp2djnvgcCw= =5T3i -----END PGP SIGNATURE----- --=-KQ3zD7tin5mww1uhb+fc-- --===============1533397931== 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://www.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade --===============1533397931==-- From lemonade-bounces@ietf.org Wed Jun 4 09:30:42 2008 Return-Path: X-Original-To: lemonade-archive@optimus.ietf.org Delivered-To: ietfarch-lemonade-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 657CF28C191; Wed, 4 Jun 2008 09:30:42 -0700 (PDT) X-Original-To: lemonade@core3.amsl.com Delivered-To: lemonade@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AE25C28C18F for ; Wed, 4 Jun 2008 09:30:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.483 X-Spam-Level: X-Spam-Status: No, score=-6.483 tagged_above=-999 required=5 tests=[AWL=0.116, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GCPT5eMdHQO9 for ; Wed, 4 Jun 2008 09:30:39 -0700 (PDT) Received: from dovecot.org (dovecot.org [82.118.211.50]) by core3.amsl.com (Postfix) with ESMTP id 8EB1828C1CF for ; Wed, 4 Jun 2008 09:30:38 -0700 (PDT) Received: from [192.168.10.2] (xdsl-177-118.nblnetworks.fi [217.30.177.118]) by dovecot.org (Postfix) with ESMTP id 50C7316471E2; Wed, 4 Jun 2008 19:30:12 +0300 (EEST) From: Timo Sirainen To: Dave Cridland In-Reply-To: <1695.1212514262.389177@peirce.dave.cridland.net> References: <1212503709.3904.654.camel@hurina> <1695.1212514262.389177@peirce.dave.cridland.net> Date: Wed, 04 Jun 2008 19:30:11 +0300 Message-Id: <1212597011.3904.753.camel@hurina> Mime-Version: 1.0 X-Mailer: Evolution 2.22.1 Cc: Enhancements to Internet email to support diverse service enivronments Subject: Re: [lemonade] CONTEXT X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0870801234==" Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org --===============0870801234== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-OVWInuGZeo+G3XOF1tO1" --=-OVWInuGZeo+G3XOF1tO1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tue, 2008-06-03 at 18:31 +0100, Dave Cridland wrote: > On Tue Jun 3 15:35:09 2008, Timo Sirainen wrote: > > 1) If ADDTO refers to newly added messages, shouldn't it be =20 > > required to > > be sent after EXISTS, just like REMOVETO must be sent before =20 > > EXPUNGE? So > > an example session would look like: > >=20 > > B01 SEARCH RETURN (UPDATE) ALL > > * ESEARCH (TAG "B01") 1 > > B01 OK > > .. > > * 1 EXPUNGE > > =EF=BB=BF* ESEARCH (TAG "B01") UID REMOVEFROM (0 1) > > * 1 EXISTS > > * ESEARCH (TAG "B01") UID ADDTO (0 1) > >=20 > >=20 > REMOVEFROM only needs to be sent prior to EXPUNGE if it refers to =20 > MSNs, since otherwise it is impossible to reference the message to be =20 > removed from the context - it's not a matter of event ordering, =20 > both the REMOVEFROM and EXPUNGE occur simultaneously by definition - =20 > it's a matter of when they can be reported. Yes, but I think it's a bit dirty to report sequences that haven't been announced yet with EXISTS. It's the same as if server replies: * 1 FETCH (FLAGS (\Seen)) * 1 EXISTS Sure the client could understand that the EXISTS probably arrives soon, but it complicates the code and error handling. What if the server is buggy and the EXISTS never arrives? It's more difficult to catch bugs if you have to look at future untagged replies to see if something is a bug or not. > > 2) Is the context position really all that useful in ESEARCH =20 > > replies? > > With sequence numbers they're completely useless and with UIDs I'd =20 > > think > > it's better to optimize for bandwidth usage rather than for the tiny > > help in client's CPU usage. > >=20 > >=20 > No, they have low utility in both SEARCH and UID SEARCH. By "low =20 > utility", I mean marginally more useful than marginal utility - I =20 > wouldn't get too exicited by them. Right, I somehow thought the position would be the same as the sequence, but obviously they're (usually) different. > The bulk of the utility is in figuring out where, in the context, the =20 > results you have are, given the change. For results you had before =20 > the change, this is always possible for a SEARCH-derived context, =20 > whereas for the results you get in an ADDTO, the context position can =20 > tell you. (Or in some cases you can logically determine where the =20 > results lie). Since the messages are sorted by UID/MSN in SEARCH result, I'd think you could always quite easily determine where the results are? > > If 2) gets changed, it would make it > > clearer that ADDTO/REMOVEFROM has the context position. > >=20 > > Also the context position description could use several examples to =20 > > make > > sure the implementors get it right. >=20 > Possibly, but this might be going beyond what I can safely do in =20 > AUTH48 - however, as it's not yet gone through the IESG telechat, =20 > I'll ask Chris. I'd note that I'm unlikely to introduce new examples =20 > unless they're more or less written for me and posted to the list for =20 > people to check. I'll probably implement it soon and could then give examples (and see that they give the same results in your implementation). --=-OVWInuGZeo+G3XOF1tO1 Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQBIRsMTyUhSUUBViskRAq5fAJ99DzRNP7pIL8z1E2kESwKebXh2LQCeKOxf flh7LTZU0d97a529lsAbsNA= =6AXe -----END PGP SIGNATURE----- --=-OVWInuGZeo+G3XOF1tO1-- --===============0870801234== 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://www.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade --===============0870801234==-- From lemonade-bounces@ietf.org Wed Jun 4 09:46:43 2008 Return-Path: X-Original-To: lemonade-archive@optimus.ietf.org Delivered-To: ietfarch-lemonade-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9B64A3A6943; Wed, 4 Jun 2008 09:46:43 -0700 (PDT) X-Original-To: lemonade@core3.amsl.com Delivered-To: lemonade@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B12913A6943 for ; Wed, 4 Jun 2008 09:46:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.499 X-Spam-Level: X-Spam-Status: No, score=-6.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RGeVZQdm2eXI for ; Wed, 4 Jun 2008 09:46:40 -0700 (PDT) Received: from dovecot.org (dovecot.org [82.118.211.50]) by core3.amsl.com (Postfix) with ESMTP id D52D43A68A9 for ; Wed, 4 Jun 2008 09:46:39 -0700 (PDT) Received: from [192.168.10.2] (xdsl-177-118.nblnetworks.fi [217.30.177.118]) by dovecot.org (Postfix) with ESMTP id 11826FA89EE; Wed, 4 Jun 2008 19:46:13 +0300 (EEST) From: Timo Sirainen To: Dave Cridland In-Reply-To: <1695.1212514290.947745@peirce.dave.cridland.net> References: <1212503709.3904.654.camel@hurina> <1212512268.3904.668.camel@hurina> <1695.1212514290.947745@peirce.dave.cridland.net> Date: Wed, 04 Jun 2008 19:46:12 +0300 Message-Id: <1212597972.3904.770.camel@hurina> Mime-Version: 1.0 X-Mailer: Evolution 2.22.1 Cc: Enhancements to Internet email to support diverse service enivronments Subject: Re: [lemonade] CONTEXT X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1270842180==" Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org --===============1270842180== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-lkIHoGnQ98c47DdNOjGw" --=-lkIHoGnQ98c47DdNOjGw Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tue, 2008-06-03 at 18:31 +0100, Dave Cridland wrote: > On Tue Jun 3 17:57:48 2008, Timo Sirainen wrote: > > On Tue, 2008-06-03 at 17:35 +0300, Timo Sirainen wrote: > > > 2) Is the context position really all that useful in ESEARCH =20 > > replies? > > > With sequence numbers they're completely useless and with UIDs =20 > > I'd think > > > it's better to optimize for bandwidth usage rather than for the =20 > > tiny > > > help in client's CPU usage. > >=20 > > How about making the context positions completely optional, even for > > SORT? I was just thinking that my virtual mailbox implementation =20 > > should > > probably do the initial build by sorting matching messages by > > INTERNALDATE, but all newly seen messages would be added to end of =20 > > the > > mailbox. So I would want to use SORT RETURN (UPDATE), but I wouldn't > > want to see context positions. > >=20 > >=20 > You're talking about a client, here, or the server?=20 =EF=BB=BFI'll implement them internally to server, but since there's a lot = of common functionality with SEARCH=3DCONTEXT, I thought I'd implement both using the same backend functions. And that means IMAP clients could implement virtual mailboxes the same way. > If you're =20 > describing client behaviour, the problem is that you're going to have =20 > to obtain a full result set initially, otherwise you'll have no =20 > idea "where" the results are that you need to remove. So you're thinking that it would be more useful if clients used a PARTIAL initial search? Yes, I guess that would be better. > The reason it's always present, but optional for servers in the case =20 > of SEARCH, is that it's just a "nice to have" for clients requesting =20 > SEARCH, whereas it can be quite painful to implement for servers, so =20 > it's nice to leave it optional. I guess I've three problems with it (with SEARCH, not with SORT): 1) It wastes bandwidth and server resources =EF=BB=BFa bit for clients that don't care about it. Should I even bother implementing it? If I did, does it hurt clients more (by wasted bandwidth) than not implementing it? I'm not sure. 2) Complicates client code. They have to implement two ways to do the same thing. Using the position could give a tiny bit of better performance, but if I implemented such code I'd still add a check to verify that the server's position actually was correct (there are so many bugs in server implementations already..). So would a client implementor even bother to implement this or just use the same code for all servers? 3) It makes it more difficult to write generic =EF=BB=BFtest cases, since t= here are two just as acceptable ways to reply. So I guess my preferred way of making it work would be to never send context position with SEARCH (more important), and make it client-configurable for SORT (less important). --=-lkIHoGnQ98c47DdNOjGw Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQBIRsbUyUhSUUBViskRAoz4AKCkmp97bDW4wVybkiCQr0afNQlHnwCfcOnv 8sS035HJw7g2QI4tYpWf3Lk= =NIXj -----END PGP SIGNATURE----- --=-lkIHoGnQ98c47DdNOjGw-- --===============1270842180== 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://www.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade --===============1270842180==-- From lemonade-bounces@ietf.org Wed Jun 4 10:57:16 2008 Return-Path: X-Original-To: lemonade-archive@optimus.ietf.org Delivered-To: ietfarch-lemonade-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 18F8D28C1FB; Wed, 4 Jun 2008 10:57:16 -0700 (PDT) X-Original-To: lemonade@core3.amsl.com Delivered-To: lemonade@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5185228C1FB for ; Wed, 4 Jun 2008 10:57:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3NTGkZqvoRqR for ; Wed, 4 Jun 2008 10:57:12 -0700 (PDT) Received: from mta02.zimbra.com (mta02.zimbra.com [77.67.121.28]) by core3.amsl.com (Postfix) with ESMTP id E0BF828C1EA for ; Wed, 4 Jun 2008 10:57:12 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mta02.zimbra.com (Postfix) with ESMTP id 2A383C78697; Wed, 4 Jun 2008 10:57:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at Received: from mta02.zimbra.com ([127.0.0.1]) by localhost (mta02.zimbra.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3+IyCimbTNj6; Wed, 4 Jun 2008 10:57:11 -0700 (PDT) Received: from dogfood.zimbra.com (dogfood.zimbra.com [10.10.140.44]) by mta02.zimbra.com (Postfix) with ESMTP id BC936C7832E; Wed, 4 Jun 2008 10:57:11 -0700 (PDT) Date: Wed, 4 Jun 2008 10:57:16 -0700 (PDT) From: Dan Karp To: Timo Sirainen Message-ID: <812784514.41791212602236400.JavaMail.root@dogfood.zimbra.com> In-Reply-To: <1082364954.41681212602208909.JavaMail.root@dogfood.zimbra.com> MIME-Version: 1.0 X-Mailer: Zimbra 5.0.7_GA_2351.RHEL4_64 (ZimbraWebClient - FF2.0 (Win)/5.0.7_GA_2351.RHEL4_64) Cc: Enhancements to Internet email to support diverse service enivronments Subject: Re: [lemonade] CONTEXT X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org > 2) Complicates client code. They have to implement two ways to do the > same thing. Using the position could give a tiny bit of better > performance, but if I implemented such code I'd still add a check to > verify that the server's position actually was correct (there are so > many bugs in server implementations already..). So would a client > implementor even bother to implement this or just use the same code > for all servers? This is a pretty good argument. Having different code paths for CONTEXT servers and non-CONTEXT servers is a pain in the ass. But if you're actually worried about buggy server implementations, I'd bet that incorrect server-side SORT ordering is much more likely than incorrect server-side CONTEXT updates. (As an aside, the idea of client-side ordering exactly matching server-side ordering is a little sketchy to begin with. In particular, for SUBJECT sorting it assumes that the client and the server share the same RFC 2047 header decoder and that they support the same set of charsets, which is unlikely to be the case.) _______________________________________________ lemonade mailing list lemonade@ietf.org https://www.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Wed Jun 4 11:14:56 2008 Return-Path: X-Original-To: lemonade-archive@optimus.ietf.org Delivered-To: ietfarch-lemonade-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 529703A6CF6; Wed, 4 Jun 2008 11:14:56 -0700 (PDT) X-Original-To: lemonade@core3.amsl.com Delivered-To: lemonade@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 22CA13A68F0 for ; Wed, 4 Jun 2008 11:14:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LP73yoE1ag1L for ; Wed, 4 Jun 2008 11:14:54 -0700 (PDT) Received: from zrtps0kn.nortel.com (zrtps0kn.nortel.com [47.140.192.55]) by core3.amsl.com (Postfix) with ESMTP id 286AA3A6CFB for ; Wed, 4 Jun 2008 11:14:12 -0700 (PDT) Received: from zcarhxm1.corp.nortel.com (zcarhxm1.corp.nortel.com [47.129.230.97]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id m54IEDS10925 for ; Wed, 4 Jun 2008 18:14:13 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 4 Jun 2008 14:13:39 -0400 Message-ID: <86CE91CAB9446F4CAED7E3C3F664DA581830EC94@zcarhxm1.corp.nortel.com> In-Reply-To: <484657A5.5070202@isode.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [lemonade] CONVERT and Lemonade Profile Bis Thread-Index: AcjGLclowVWOMbgVQoyUBF1dptVmAwAQDGvA References: <8B9B8F32-8DEF-40B9-992E-9337FB7AE344@standardstrack.com> <1210951366.9518.654.camel@hurina> <48312F7D.8090103@isode.com> <1211191304.9518.755.camel@hurina> <4835D000.4080808@isode.com> <1211745339.3904.166.camel@hurina> <483BAB35.2080806@isode.com> <1B7D968F-7A77-40FC-AFD6-ADF3C2826822@iki.fi> <484657A5.5070202@isode.com> From: "Jackson Chan" To: "lemonade" Subject: [lemonade] CONVERT and Lemonade Profile Bis X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org Quick question: What is the status of inclusion of CONVERT in Lemonade Profile Bis? _______________________________________________ lemonade mailing list lemonade@ietf.org https://www.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Wed Jun 4 11:18:15 2008 Return-Path: X-Original-To: lemonade-archive@optimus.ietf.org Delivered-To: ietfarch-lemonade-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AE2383A6CED; Wed, 4 Jun 2008 11:18:15 -0700 (PDT) X-Original-To: lemonade@core3.amsl.com Delivered-To: lemonade@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DDDFD3A6CF9 for ; Wed, 4 Jun 2008 11:18:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.512 X-Spam-Level: X-Spam-Status: No, score=-6.512 tagged_above=-999 required=5 tests=[AWL=0.087, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BOviqC69WdbF for ; Wed, 4 Jun 2008 11:18:14 -0700 (PDT) Received: from dovecot.org (dovecot.org [82.118.211.50]) by core3.amsl.com (Postfix) with ESMTP id F26CF3A6CED for ; Wed, 4 Jun 2008 11:18:13 -0700 (PDT) Received: from [192.168.10.2] (xdsl-177-118.nblnetworks.fi [217.30.177.118]) by dovecot.org (Postfix) with ESMTP id 0256BFA8B23 for ; Wed, 4 Jun 2008 21:17:46 +0300 (EEST) From: Timo Sirainen To: lemonade@ietf.org In-Reply-To: <484657A5.5070202@isode.com> References: <8B9B8F32-8DEF-40B9-992E-9337FB7AE344@standardstrack.com> <1210951366.9518.654.camel@hurina> <48312F7D.8090103@isode.com> <1211191304.9518.755.camel@hurina> <4835D000.4080808@isode.com> <1211745339.3904.166.camel@hurina> <483BAB35.2080806@isode.com> <1B7D968F-7A77-40FC-AFD6-ADF3C2826822@iki.fi> <484657A5.5070202@isode.com> Date: Wed, 04 Jun 2008 21:17:46 +0300 Message-Id: <1212603466.3904.782.camel@hurina> Mime-Version: 1.0 X-Mailer: Evolution 2.22.1 Subject: Re: [lemonade] WGLC NOTIFY X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0480758898==" Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org --===============0480758898== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-fgf58Gb7l1wWWEPLsayQ" --=-fgf58Gb7l1wWWEPLsayQ Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Wed, 2008-06-04 at 09:51 +0100, Alexey Melnikov wrote: > The reason why we have MessageExpunge and MessageNew tied together is=20 > because representative of a certain company kept moaning that he can't=20 > implement them separately. I forgot to mention in my previous mail: I don't think it's unreasonable for an extension to require servers to implement the base IMAP4 protocol correctly. Untied MessageNew and MessageExpunge handling is already required for FETCH/STORE/SEARCH handling. If a server has trouble implementing them untied, it's already either broken or nonoptimal. If the server doesn't do EXISTS notifications for FETCH/STORE/SEARCH, it could implement NOTIFY the exact same way: EXISTS notifications are sent only when EXPUNGE notifications are also legal. --=-fgf58Gb7l1wWWEPLsayQ Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQBIRtxKyUhSUUBViskRAn7xAJ98Eg8N71k4mnub3zTcUF3MNw0fLACgkiUV G3azvEFWK2Mbs6WoLS9qtqY= =/M8t -----END PGP SIGNATURE----- --=-fgf58Gb7l1wWWEPLsayQ-- --===============0480758898== 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://www.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade --===============0480758898==-- From lemonade-bounces@ietf.org Wed Jun 4 11:29:54 2008 Return-Path: X-Original-To: lemonade-archive@optimus.ietf.org Delivered-To: ietfarch-lemonade-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 437293A6D05; Wed, 4 Jun 2008 11:29:54 -0700 (PDT) X-Original-To: lemonade@core3.amsl.com Delivered-To: lemonade@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 957473A6CFF for ; Wed, 4 Jun 2008 11:29:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.45 X-Spam-Level: X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[AWL=0.149, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ab+AO+gPMUgr for ; Wed, 4 Jun 2008 11:29:52 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id 783223A6D0C for ; Wed, 4 Jun 2008 11:29:36 -0700 (PDT) Received: from [172.16.2.192] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Wed, 4 Jun 2008 19:29:40 +0100 Message-ID: <4846DEEE.2050506@isode.com> Date: Wed, 04 Jun 2008 19:29:02 +0100 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: Jackson Chan References: <8B9B8F32-8DEF-40B9-992E-9337FB7AE344@standardstrack.com> <1210951366.9518.654.camel@hurina> <48312F7D.8090103@isode.com> <1211191304.9518.755.camel@hurina> <4835D000.4080808@isode.com> <1211745339.3904.166.camel@hurina> <483BAB35.2080806@isode.com> <1B7D968F-7A77-40FC-AFD6-ADF3C2826822@iki.fi> <484657A5.5070202@isode.com> <86CE91CAB9446F4CAED7E3C3F664DA581830EC94@zcarhxm1.corp.nortel.com> In-Reply-To: <86CE91CAB9446F4CAED7E3C3F664DA581830EC94@zcarhxm1.corp.nortel.com> MIME-Version: 1.0 Cc: lemonade Subject: Re: [lemonade] CONVERT and Lemonade Profile Bis X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org Hi Jackson, Jackson Chan wrote: >Quick question: > >What is the status of inclusion of CONVERT in Lemonade Profile Bis? > > CONVERT is a mandatory feature in Lemonade Profile Bis and there is no plan to take CONVERT out. Regards, Alexey _______________________________________________ lemonade mailing list lemonade@ietf.org https://www.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Wed Jun 4 15:03:34 2008 Return-Path: X-Original-To: lemonade-archive@optimus.ietf.org Delivered-To: ietfarch-lemonade-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D7BE53A6D53; Wed, 4 Jun 2008 15:03:31 -0700 (PDT) X-Original-To: lemonade@core3.amsl.com Delivered-To: lemonade@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 20FE23A6B1E for ; Wed, 4 Jun 2008 15:03:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.521 X-Spam-Level: X-Spam-Status: No, score=-6.521 tagged_above=-999 required=5 tests=[AWL=0.078, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AZpgOKhKCBMb for ; Wed, 4 Jun 2008 15:03:20 -0700 (PDT) Received: from dovecot.org (dovecot.org [82.118.211.50]) by core3.amsl.com (Postfix) with ESMTP id 961293A6D3C for ; Wed, 4 Jun 2008 15:03:17 -0700 (PDT) Received: from [192.168.10.2] (xdsl-177-118.nblnetworks.fi [217.30.177.118]) by dovecot.org (Postfix) with ESMTP id 2D7EB16471F6 for ; Thu, 5 Jun 2008 01:02:41 +0300 (EEST) From: Timo Sirainen To: lemonade@ietf.org Date: Thu, 05 Jun 2008 01:02:40 +0300 Message-Id: <1212616960.3904.802.camel@hurina> Mime-Version: 1.0 X-Mailer: Evolution 2.22.1 Subject: [lemonade] CONTEXT with sequence searches X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0384206867==" Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org --===============0384206867== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-qtmtEGZkm6PqIDDF/TUf" --=-qtmtEGZkm6PqIDDF/TUf Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable If a mailbox has 3+ messages and I use: 1 SEARCH RETURN (UPDATE) 2 * ESEARCH (TAG "1") 2 1 OK What happens when the first message gets expunged? a) Nothing? (What if second message gets expunged?) b) =EF=BB=BF=EF=BB=BF=EF=BB=BF* ESEARCH (TAG "1") UID REMOVEFROM (0 2) * 1 EXPUNGE * ESEARCH (TAG "1") UID ADDTO (0 2) I think I prefer b). Then it would match the (required?) behavior of: 2 UID SEARCH RETURN (UPDATE) 2 =EF=BB=BF* ESEARCH (TAG "2") 123 2 OK ..=EF=BB=BF * ESEARCH (TAG "2") UID REMOVEFROM (0 123) * 1 EXPUNGE * ESEARCH (TAG "2") UID ADDTO (0 124) I think these would be a good examples in the spec, because they're not that obvious. --=-qtmtEGZkm6PqIDDF/TUf Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQBIRxEAyUhSUUBViskRAjxWAJ4tfbbpFx5Wlf4T9HusfWlrveoHggCeN6fc 6wG9Re/35zBsH0OSM5wVWc4= =0e1w -----END PGP SIGNATURE----- --=-qtmtEGZkm6PqIDDF/TUf-- --===============0384206867== 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://www.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade --===============0384206867==-- From lemonade-bounces@ietf.org Wed Jun 4 15:56:57 2008 Return-Path: X-Original-To: lemonade-archive@optimus.ietf.org Delivered-To: ietfarch-lemonade-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 674A43A6903; Wed, 4 Jun 2008 15:56:57 -0700 (PDT) X-Original-To: lemonade@core3.amsl.com Delivered-To: lemonade@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 995083A6903 for ; Wed, 4 Jun 2008 15:56:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.529 X-Spam-Level: X-Spam-Status: No, score=-6.529 tagged_above=-999 required=5 tests=[AWL=0.070, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JPlbKiPbQCnx for ; Wed, 4 Jun 2008 15:56:55 -0700 (PDT) Received: from dovecot.org (dovecot.org [82.118.211.50]) by core3.amsl.com (Postfix) with ESMTP id BE3D33A68FB for ; Wed, 4 Jun 2008 15:56:55 -0700 (PDT) Received: from [192.168.10.2] (xdsl-177-118.nblnetworks.fi [217.30.177.118]) by dovecot.org (Postfix) with ESMTP id 982E816471E7 for ; Thu, 5 Jun 2008 01:56:29 +0300 (EEST) From: Timo Sirainen To: lemonade In-Reply-To: <1212503709.3904.654.camel@hurina> References: <1212503709.3904.654.camel@hurina> Date: Thu, 05 Jun 2008 01:56:28 +0300 Message-Id: <1212620188.3904.819.camel@hurina> Mime-Version: 1.0 X-Mailer: Evolution 2.22.1 Subject: Re: [lemonade] CONTEXT X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0487949055==" Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org --===============0487949055== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-OGnHJQf8wUTGMZhQTuHW" --=-OGnHJQf8wUTGMZhQTuHW Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Is tag matching in CANCELUPDATE case-sensitive? Probably would be better if it was, but since IMAP is usually case-insensitive this should be mentioned in the spec. --=-OGnHJQf8wUTGMZhQTuHW Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQBIRx2cyUhSUUBViskRAp9oAJ9nJUDnRgX7zi4/wXcvkbeWiXcLeACeOa/X e2qeh4qyu3CS/1CXO6lStEc= =e+Q+ -----END PGP SIGNATURE----- --=-OGnHJQf8wUTGMZhQTuHW-- --===============0487949055== 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://www.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade --===============0487949055==-- From lemonade-bounces@ietf.org Wed Jun 4 17:52:35 2008 Return-Path: X-Original-To: lemonade-archive@optimus.ietf.org Delivered-To: ietfarch-lemonade-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E0BBA3A68A3; Wed, 4 Jun 2008 17:52:35 -0700 (PDT) X-Original-To: lemonade@core3.amsl.com Delivered-To: lemonade@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6C78D3A69AD for ; Wed, 4 Jun 2008 17:52:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qkLtd-v6QgdC for ; Wed, 4 Jun 2008 17:52:34 -0700 (PDT) Received: from mta02.zimbra.com (mta02.zimbra.com [77.67.121.28]) by core3.amsl.com (Postfix) with ESMTP id 633343A68A3 for ; Wed, 4 Jun 2008 17:52:33 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mta02.zimbra.com (Postfix) with ESMTP id 89BA9C7873E; Wed, 4 Jun 2008 17:52:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at Received: from mta02.zimbra.com ([127.0.0.1]) by localhost (mta02.zimbra.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rIoKymFhqmk6; Wed, 4 Jun 2008 17:52:32 -0700 (PDT) Received: from dogfood.zimbra.com (dogfood.zimbra.com [10.10.140.44]) by mta02.zimbra.com (Postfix) with ESMTP id 4BDF7C7873A; Wed, 4 Jun 2008 17:52:32 -0700 (PDT) Date: Wed, 4 Jun 2008 17:52:37 -0700 (PDT) From: Dan Karp To: Timo Sirainen Message-ID: <367401715.23521212627157590.JavaMail.root@dogfood.zimbra.com> In-Reply-To: <1617850882.23461212626991705.JavaMail.root@dogfood.zimbra.com> MIME-Version: 1.0 X-Mailer: Zimbra 5.0.7_GA_2351.RHEL4_64 (ZimbraWebClient - FF2.0 (Win)/5.0.7_GA_2351.RHEL4_64) Cc: lemonade@ietf.org Subject: Re: [lemonade] CONTEXT with sequence searches X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org > If a mailbox has 3+ messages and I use: > > 1 SEARCH RETURN (UPDATE) 2 > * ESEARCH (TAG "1") 2 > 1 OK I was under the impression that sequence sets (and UID sets) in SEARCH/SORT contexts applied only at SEARCH/SORT time. So "2" in your example would mean "the message at sequence 2 at time of search", not "whichever message currently occupies sequence 2". The latter interpretation doesn't seem real-world useful. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Wed Jun 4 18:06:14 2008 Return-Path: X-Original-To: lemonade-archive@optimus.ietf.org Delivered-To: ietfarch-lemonade-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 260543A6963; Wed, 4 Jun 2008 18:06:13 -0700 (PDT) X-Original-To: lemonade@core3.amsl.com Delivered-To: lemonade@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 98E233A68FB for ; Wed, 4 Jun 2008 18:06:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.536 X-Spam-Level: X-Spam-Status: No, score=-6.536 tagged_above=-999 required=5 tests=[AWL=0.063, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fi-gyGuN9GWM for ; Wed, 4 Jun 2008 18:06:09 -0700 (PDT) Received: from dovecot.org (dovecot.org [82.118.211.50]) by core3.amsl.com (Postfix) with ESMTP id E9DA93A67B5 for ; Wed, 4 Jun 2008 18:06:08 -0700 (PDT) Received: from [192.168.10.2] (xdsl-177-118.nblnetworks.fi [217.30.177.118]) by dovecot.org (Postfix) with ESMTP id 069A016471F0; Thu, 5 Jun 2008 04:05:39 +0300 (EEST) From: Timo Sirainen To: Dan Karp In-Reply-To: <367401715.23521212627157590.JavaMail.root@dogfood.zimbra.com> References: <367401715.23521212627157590.JavaMail.root@dogfood.zimbra.com> Date: Thu, 05 Jun 2008 04:05:39 +0300 Message-Id: <1212627939.3904.838.camel@hurina> Mime-Version: 1.0 X-Mailer: Evolution 2.22.1 Cc: lemonade@ietf.org Subject: Re: [lemonade] CONTEXT with sequence searches X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0626323515==" Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org --===============0626323515== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-/XeuNM6YXg4DKnCjLkZe" --=-/XeuNM6YXg4DKnCjLkZe Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Wed, 2008-06-04 at 17:52 -0700, Dan Karp wrote: > > If a mailbox has 3+ messages and I use: > >=20 > > 1 SEARCH RETURN (UPDATE) 2 > > * ESEARCH (TAG "1") 2 > > 1 OK >=20 > I was under the impression that sequence sets (and UID sets) in > SEARCH/SORT contexts applied only at SEARCH/SORT time. So "2" > in your example would mean "the message at sequence 2 at time of > search", not "whichever message currently occupies sequence 2". I don't really see this specified one way or another anywhere. But your interpretation could be better, or at least it's a lot easier to implement. > The latter interpretation doesn't seem real-world useful. One potential use case would be a PARTIAL replacement. Like "show me first 100 messages" where they get updated whenever messages get expunged. But I guess that's not all that useful. --=-/XeuNM6YXg4DKnCjLkZe Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQBIRzvjyUhSUUBViskRAhotAJ9Ax7HFup+pcuF/Rz/oEEXhUKNlNwCgoh7Z Q/LY8DUWAv7RCU3/sRjQRIA= =xAj2 -----END PGP SIGNATURE----- --=-/XeuNM6YXg4DKnCjLkZe-- --===============0626323515== 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://www.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade --===============0626323515==-- From lemonade-bounces@ietf.org Wed Jun 4 18:30:06 2008 Return-Path: X-Original-To: lemonade-archive@optimus.ietf.org Delivered-To: ietfarch-lemonade-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3BB3C3A69D4; Wed, 4 Jun 2008 18:30:06 -0700 (PDT) X-Original-To: lemonade@core3.amsl.com Delivered-To: lemonade@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 328183A68B5 for ; Wed, 4 Jun 2008 18:30:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xnDLUKYugmoz for ; Wed, 4 Jun 2008 18:30:04 -0700 (PDT) Received: from mta02.zimbra.com (mta02.zimbra.com [77.67.121.28]) by core3.amsl.com (Postfix) with ESMTP id 780D03A685F for ; Wed, 4 Jun 2008 18:30:04 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mta02.zimbra.com (Postfix) with ESMTP id 5BFE0C782EF; Wed, 4 Jun 2008 18:30:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at Received: from mta02.zimbra.com ([127.0.0.1]) by localhost (mta02.zimbra.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YMcDF0c9-JhD; Wed, 4 Jun 2008 18:30:03 -0700 (PDT) Received: from dogfood.zimbra.com (dogfood.zimbra.com [10.10.140.44]) by mta02.zimbra.com (Postfix) with ESMTP id F2A61C78273; Wed, 4 Jun 2008 18:30:02 -0700 (PDT) Date: Wed, 4 Jun 2008 18:30:08 -0700 (PDT) From: Dan Karp To: Timo Sirainen Message-ID: <161364605.24491212629408264.JavaMail.root@dogfood.zimbra.com> In-Reply-To: <1310884173.24311212629143580.JavaMail.root@dogfood.zimbra.com> MIME-Version: 1.0 X-Mailer: Zimbra 5.0.7_GA_2351.RHEL4_64 (ZimbraWebClient - FF2.0 (Win)/5.0.7_GA_2351.RHEL4_64) Cc: lemonade@ietf.org Subject: Re: [lemonade] CONTEXT with sequence searches X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org > > I was under the impression that sequence sets (and UID sets) in > > SEARCH/SORT contexts applied only at SEARCH/SORT time. So "2" > > in your example would mean "the message at sequence 2 at time of > > search", not "whichever message currently occupies sequence 2". > > I don't really see this specified one way or another anywhere. But > your interpretation could be better, or at least it's a lot easier > to implement. You're right that the draft needs to specify this behavior. It has to weigh in on OLDER/YOUNGER, too. (Like you, I'm rooting for the easier-to-implement interpretation.) _______________________________________________ lemonade mailing list lemonade@ietf.org https://www.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Wed Jun 4 18:55:08 2008 Return-Path: X-Original-To: lemonade-archive@optimus.ietf.org Delivered-To: ietfarch-lemonade-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 945123A685F; Wed, 4 Jun 2008 18:55:08 -0700 (PDT) X-Original-To: lemonade@core3.amsl.com Delivered-To: lemonade@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EB1073A685F for ; Wed, 4 Jun 2008 18:55:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.541 X-Spam-Level: X-Spam-Status: No, score=-6.541 tagged_above=-999 required=5 tests=[AWL=0.058, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DMT3iItaruPV for ; Wed, 4 Jun 2008 18:55:07 -0700 (PDT) Received: from dovecot.org (dovecot.org [82.118.211.50]) by core3.amsl.com (Postfix) with ESMTP id 1012B3A685A for ; Wed, 4 Jun 2008 18:55:07 -0700 (PDT) Received: from [192.168.10.2] (xdsl-177-118.nblnetworks.fi [217.30.177.118]) by dovecot.org (Postfix) with ESMTP id ED4C016471F0; Thu, 5 Jun 2008 04:54:40 +0300 (EEST) From: Timo Sirainen To: Dan Karp In-Reply-To: <161364605.24491212629408264.JavaMail.root@dogfood.zimbra.com> References: <161364605.24491212629408264.JavaMail.root@dogfood.zimbra.com> Date: Thu, 05 Jun 2008 04:54:40 +0300 Message-Id: <1212630880.3904.841.camel@hurina> Mime-Version: 1.0 X-Mailer: Evolution 2.22.1 Cc: lemonade@ietf.org Subject: Re: [lemonade] CONTEXT with sequence searches X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0943838422==" Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org --===============0943838422== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-Ko9d3sHzO+uNKcYn3R8x" --=-Ko9d3sHzO+uNKcYn3R8x Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Wed, 2008-06-04 at 18:30 -0700, Dan Karp wrote: > > > I was under the impression that sequence sets (and UID sets) in > > > SEARCH/SORT contexts applied only at SEARCH/SORT time. So "2" > > > in your example would mean "the message at sequence 2 at time of > > > search", not "whichever message currently occupies sequence 2". > >=20 > > I don't really see this specified one way or another anywhere. But > > your interpretation could be better, or at least it's a lot easier > > to implement. >=20 > You're right that the draft needs to specify this behavior. It has > to weigh in on OLDER/YOUNGER, too. (Like you, I'm rooting for the > easier-to-implement interpretation.) Oh, right. I forgot OLDER/YOUNGER since I implemented it before CONTEXT. But at least that's clearly defined in the WITHIN RFC: Both OLDER and YOUNGER searches always result in exact matching, to the resolution of a second. However, if one is doing a dynamic evaluation, for example, in a context [CONTEXT], one needs to be aware that the server might perform the evaluation periodically. --=-Ko9d3sHzO+uNKcYn3R8x Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQBIR0dgyUhSUUBViskRAhfTAKCmAHOD/WquSARkwkbRbGGIAbN8hgCggvYw pDB3tPBM6xx17l1WpCQjN8c= =r7mk -----END PGP SIGNATURE----- --=-Ko9d3sHzO+uNKcYn3R8x-- --===============0943838422== 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://www.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade --===============0943838422==-- From lemonade-bounces@ietf.org Thu Jun 5 01:54:45 2008 Return-Path: X-Original-To: lemonade-archive@optimus.ietf.org Delivered-To: ietfarch-lemonade-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 490363A6BBF; Thu, 5 Jun 2008 01:54:45 -0700 (PDT) X-Original-To: lemonade@core3.amsl.com Delivered-To: lemonade@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5656C3A6B59 for ; Thu, 5 Jun 2008 01:54:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2Es3R-On0oni for ; Thu, 5 Jun 2008 01:54:43 -0700 (PDT) Received: from turner.dave.cridland.net (unknown [IPv6:2001:838:378:0:211:9ff:fe2c:e28e]) by core3.amsl.com (Postfix) with ESMTP id 3B4AE3A6BBF for ; Thu, 5 Jun 2008 01:54:42 -0700 (PDT) Received: from peirce.dave.cridland.net ([217.155.137.61]) by turner.dave.cridland.net (submission) via TCP with ESMTPA id ; Thu, 5 Jun 2008 09:54:20 +0100 References: <1212503709.3904.654.camel@hurina> <1212512268.3904.668.camel@hurina> <1695.1212514290.947745@peirce.dave.cridland.net> <1212597972.3904.770.camel@hurina> In-Reply-To: <1212597972.3904.770.camel@hurina> MIME-Version: 1.0 Message-Id: <1695.1212656059.788733@peirce.dave.cridland.net> Date: Thu, 05 Jun 2008 09:54:19 +0100 From: Dave Cridland To: Timo Sirainen X-Encoded: Changed encoding from 8Bit for 7bit transmission Cc: Enhancements to Internet email to support diverse service enivronments Subject: Re: [lemonade] CONTEXT X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org T24gV2VkIEp1biAgNCAxNzo0NjoxMiAyMDA4LCBUaW1vIFNpcmFpbmVuIHdyb3RlOgo+IE9uIFR1 ZSwgMjAwOC0wNi0wMyBhdCAxODozMSArMDEwMCwgRGF2ZSBDcmlkbGFuZCB3cm90ZToKPiA+IE9u IFR1ZSBKdW4gIDMgMTc6NTc6NDggMjAwOCwgVGltbyBTaXJhaW5lbiB3cm90ZToKPiA+ID4gT24g VHVlLCAyMDA4LTA2LTAzIGF0IDE3OjM1ICswMzAwLCBUaW1vIFNpcmFpbmVuIHdyb3RlOgo+ID4g PiA+IDIpIElzIHRoZSBjb250ZXh0IHBvc2l0aW9uIHJlYWxseSBhbGwgdGhhdCB1c2VmdWwgaW4g RVNFQVJDSAo+ID4gPiByZXBsaWVzPwo+ID4gPiA+IFdpdGggc2VxdWVuY2UgbnVtYmVycyB0aGV5 J3JlIGNvbXBsZXRlbHkgdXNlbGVzcyBhbmQgd2l0aCBVSURzCj4gPiA+IEknZCB0aGluawo+ID4g PiA+IGl0J3MgYmV0dGVyIHRvIG9wdGltaXplIGZvciBiYW5kd2lkdGggdXNhZ2UgcmF0aGVyIHRo YW4gZm9yICAKPiB0aGUKPiA+ID4gdGlueQo+ID4gPiA+IGhlbHAgaW4gY2xpZW50J3MgQ1BVIHVz YWdlLgo+ID4gPgo+ID4gPiBIb3cgYWJvdXQgbWFraW5nIHRoZSBjb250ZXh0IHBvc2l0aW9ucyBj b21wbGV0ZWx5IG9wdGlvbmFsLCAgCj4gZXZlbiBmb3IKPiA+ID4gU09SVD8gSSB3YXMganVzdCB0 aGlua2luZyB0aGF0IG15IHZpcnR1YWwgbWFpbGJveCBpbXBsZW1lbnRhdGlvbgo+ID4gPiBzaG91 bGQKPiA+ID4gcHJvYmFibHkgZG8gdGhlIGluaXRpYWwgYnVpbGQgYnkgc29ydGluZyBtYXRjaGlu ZyBtZXNzYWdlcyBieQo+ID4gPiBJTlRFUk5BTERBVEUsIGJ1dCBhbGwgbmV3bHkgc2VlbiBtZXNz YWdlcyB3b3VsZCBiZSBhZGRlZCB0byBlbmQgIAo+IG9mCj4gPiA+IHRoZQo+ID4gPiBtYWlsYm94 LiBTbyBJIHdvdWxkIHdhbnQgdG8gdXNlIFNPUlQgUkVUVVJOIChVUERBVEUpLCBidXQgSSAgCj4g d291bGRuJ3QKPiA+ID4gd2FudCB0byBzZWUgY29udGV4dCBwb3NpdGlvbnMuCj4gPiA+Cj4gPiA+ Cj4gPiBZb3UncmUgdGFsa2luZyBhYm91dCBhIGNsaWVudCwgaGVyZSwgb3IgdGhlIHNlcnZlcj8K PiAKPiDvu79JJ2xsIGltcGxlbWVudCB0aGVtIGludGVybmFsbHkgdG8gc2VydmVyLCBidXQgc2lu Y2UgdGhlcmUncyBhICAKPiBsb3Qgb2YKPiBjb21tb24gZnVuY3Rpb25hbGl0eSB3aXRoIFNFQVJD SD1DT05URVhULCBJIHRob3VnaHQgSSdkIGltcGxlbWVudCAgCj4gYm90aAo+IHVzaW5nIHRoZSBz YW1lIGJhY2tlbmQgZnVuY3Rpb25zLiBBbmQgdGhhdCBtZWFucyBJTUFQIGNsaWVudHMgY291bGQK PiBpbXBsZW1lbnQgdmlydHVhbCBtYWlsYm94ZXMgdGhlIHNhbWUgd2F5Lgo+IAo+IApJTUFQIGNs aWVudCBjYW4gYWxyZWFkeSBpbXBsZW1lbnQgdmlydHVhbCBtYWlsYm94ZXMgdXNpbmcgQ09OVEVY VCAgCndpdGggZWl0aGVyIG9mIFNFQVJDSCBvciBTT1JUIC0gaXQncyBqdXN0IHRoYXQgbWVzc2Fn ZXMgd291bGRuJ3QgIAphbHdheXMgYXBwZWFyIGF0IHRoZSBlbmQgLSB0aGlzIGlzIG9rYXkgZm9y IGEgU09SVGVkIHZpZXcsIGFsdGhvdWdoIGEgIApsaXR0bGUgc3VycHJpc2luZyBmb3Igb25lIGJh c2VkIG9uIGEgU0VBUkNIIC0gbHVja2lseSwgaXQncyBhbHNvIHZlcnkgIAp1bmxpa2VseS4KCgo+ ID4gSWYgeW91J3JlCj4gPiBkZXNjcmliaW5nIGNsaWVudCBiZWhhdmlvdXIsIHRoZSBwcm9ibGVt IGlzIHRoYXQgeW91J3JlIGdvaW5nIHRvICAKPiBoYXZlCj4gPiAgIHRvIG9idGFpbiBhIGZ1bGwg cmVzdWx0IHNldCBpbml0aWFsbHksIG90aGVyd2lzZSB5b3UnbGwgaGF2ZSBubwo+ID4gaWRlYSAg IndoZXJlIiB0aGUgcmVzdWx0cyBhcmUgdGhhdCB5b3UgbmVlZCB0byByZW1vdmUuCj4gCj4gU28g eW91J3JlIHRoaW5raW5nIHRoYXQgaXQgd291bGQgYmUgbW9yZSB1c2VmdWwgaWYgY2xpZW50cyB1 c2VkIGEKPiBQQVJUSUFMIGluaXRpYWwgc2VhcmNoPyBZZXMsIEkgZ3Vlc3MgdGhhdCB3b3VsZCBi ZSBiZXR0ZXIuCj4gCj4gCk9yIGp1c3QgYSBDT1VOVCwgeWVzLiBZb3UgY2FuIG9ubHkgZW50aXJl bHkgZHJvcCB0aGUgcG9zaXRpb25zIGZvciBhICAKU0VBUkNILCBhbmQgb25seSB3aGVuIHRoZSBu dW1iZXIgb2YgcmVzdWx0cyBpcyBzbWFsbCBlbm91Z2guCgpBIGNsaWVudCBjb3VsZCBtYWtlIGEg Z3Vlc3MgYXQgdGhhdCAtIGZvciBleGFtcGxlLCBpZiB0aGUgbWFpbGJveCAgCnNpemUgaXMgc21h bGwsIHRoZW4gdGhlcmUgY2Fubm90IGJlIHN1ZmZpY2llbnQgbWF0Y2hpbmcgbWVzc2FnZXMsIGJ1 dCAgCkkndmUgbm90IGRvbmUgdGhhdCBpbiBteSBpbXBsZW1lbnRhdGlvbiAtIEkgZG8gaGFwcGVu IHRvIGRvIFBBUlRJQUxzICAKdGhhdCBleHRlbmQgYWNyb3NzIHRoZSBlbnRpcmUgcmFuZ2UgYXMg YSBieXByb2R1Y3QsIGJ1dCB0aGF0J3MgaXQuCgoKPiA+IFRoZSByZWFzb24gaXQncyBhbHdheXMg cHJlc2VudCwgYnV0IG9wdGlvbmFsIGZvciBzZXJ2ZXJzIGluIHRoZSAgCj4gY2FzZQo+ID4gb2Yg U0VBUkNILCBpcyB0aGF0IGl0J3MganVzdCBhICJuaWNlIHRvIGhhdmUiIGZvciBjbGllbnRzICAK PiByZXF1ZXN0aW5nCj4gPiBTRUFSQ0gsIHdoZXJlYXMgaXQgY2FuIGJlIHF1aXRlIHBhaW5mdWwg dG8gaW1wbGVtZW50IGZvciBzZXJ2ZXJzLCAgCj4gc28KPiA+IGl0J3MgbmljZSB0byBsZWF2ZSBp dCBvcHRpb25hbC4KPiAKPiBJIGd1ZXNzIEkndmUgdGhyZWUgcHJvYmxlbXMgd2l0aCBpdCAod2l0 aCBTRUFSQ0gsIG5vdCB3aXRoIFNPUlQpOgo+IAo+IDEpIEl0IHdhc3RlcyBiYW5kd2lkdGggYW5k IHNlcnZlciByZXNvdXJjZXMg77u/YSBiaXQgZm9yIGNsaWVudHMgIAo+IHRoYXQKPiBkb24ndCBj YXJlIGFib3V0IGl0LiBTaG91bGQgSSBldmVuIGJvdGhlciBpbXBsZW1lbnRpbmcgaXQ/IElmIEkg ZGlkLAo+IGRvZXMgaXQgaHVydCBjbGllbnRzIG1vcmUgKGJ5IHdhc3RlZCBiYW5kd2lkdGgpIHRo YW4gbm90ICAKPiBpbXBsZW1lbnRpbmcKPiBpdD8gSSdtIG5vdCBzdXJlLgo+IAo+IApJIGRvbid0 IHRoaW5rIGJhbmR3aWR0aCB1c2FnZSBpcyBzaWduaWZpY2FudCBoZXJlIC0gd2UncmUgdGFsa2lu ZyBpbiAgCnRlcm1zIG9mIHBlcmhhcHMgZm91ciBvY3RldHMgcGVyIG1lc3NhZ2UuIFlvdSBjYW4s IGluY2lkZW50YWxseSwgIAphbHdheXMgc2V0IHBvc2l0aW9uIHRvIHplcm8gZm9yIFJFTU9WRUZS T00sIGFuZCB0aGVuIHRoZXJlJ3Mgbm8gIApiYW5kd2lkdGggaGl0LCBub3IgYW55IGxvc3MgaW4g ZnVuY3Rpb25hbGl0eSB0byBhIGNsaWVudC4KCgo+IDIpIENvbXBsaWNhdGVzIGNsaWVudCBjb2Rl LiBUaGV5IGhhdmUgdG8gaW1wbGVtZW50IHR3byB3YXlzIHRvIGRvICAKPiB0aGUKPiBzYW1lIHRo aW5nLiBVc2luZyB0aGUgcG9zaXRpb24gY291bGQgZ2l2ZSBhIHRpbnkgYml0IG9mIGJldHRlcgo+ IHBlcmZvcm1hbmNlLCBidXQgaWYgSSBpbXBsZW1lbnRlZCBzdWNoIGNvZGUgSSdkIHN0aWxsIGFk ZCBhIGNoZWNrIHRvCj4gdmVyaWZ5IHRoYXQgdGhlIHNlcnZlcidzIHBvc2l0aW9uIGFjdHVhbGx5 IHdhcyBjb3JyZWN0ICh0aGVyZSBhcmUgc28KPiBtYW55IGJ1Z3MgaW4gc2VydmVyIGltcGxlbWVu dGF0aW9ucyBhbHJlYWR5Li4pLiBTbyB3b3VsZCBhIGNsaWVudAo+IGltcGxlbWVudG9yIGV2ZW4g Ym90aGVyIHRvIGltcGxlbWVudCB0aGlzIG9yIGp1c3QgdXNlIHRoZSBzYW1lIGNvZGUgIAo+IGZv cgo+IGFsbCBzZXJ2ZXJzPwo+IAo+IApXZWxsLCB0aGUgaWRlYSBpcyB0aGF0IGEgY2xpZW50IGNh biB1c2UgZXNzZW50aWFsbHkgdGhlIHNhbWUgY29kZSBmb3IgIApwcm9jZXNzaW5nIFNFQVJDSCBh bmQgU09SVCAtIHRoZSBkaWZmZXJlbmNlIGlzIHRoYXQgdGhlIGNsaWVudCBoYXMgdG8gIApjb3Bl IHdpdGggbWlzc2luZyBwb3NpdGlvbnMgZm9yIFNFQVJDSCwgYnV0IHRoZXJlJ3Mgbm8gZGlmZmVy ZW5jZSB0byAgCnRoZSBwYXJzZXIgY29kZSwgbm9yIHRoZSBwcm9jZXNzaW5nIGlmIHRoZSBwb3Np dGlvbiBpcyBzdXBwbGllZCAtICAKaGVuY2UgZmV3ZXIgY29kZSBwYXRocy4gRm9yIHRoZSBjYXNl cyB3aGVyZSB0aGUgcG9zaXRpb24gaXNuJ3QgIApzdXBwbGllZCwgdGhlIFJFTU9WRUZST00gd2ls bCBlbmQgdXAgYmVpbmcgb2theSAtIGRlbGV0ZSBhbmQvb3IgbW92ZSAgCi0gdGhlIEFERFRPIGlz IHJhdGhlciBtb3JlIHBhaW5mdWwsIGFuZCBpbnZvbHZlcyB0aHJvd2luZyBzb21lICAKcmVzdWx0 cyBhd2F5IHNvbWV0aW1lcy4KClNvIGluIGFuIGlkZWFsIHdvcmxkLCBJJ2QgbWFuZGF0ZSBwb3Np dGlvbiBiZSBwcmVzZW50IGluIGFsbCBjYXNlcywgIAphbmQgcmVtb3ZlIGFub3RoZXIgc3BlY2lh bC1jYXNlLCBidXQgSSBnb3QgYSBmYWlyIGRlZ3JlZSBvZiBwdXNoLWJhY2sgIApmcm9tIHNlcnZl ciBpbXBsZW1lbnRvcnMgb24gdGhhdCBmcm9udC4KCgo+IDMpIEl0IG1ha2VzIGl0IG1vcmUgZGlm ZmljdWx0IHRvIHdyaXRlIGdlbmVyaWMg77u/dGVzdCBjYXNlcywgc2luY2UgIAo+IHRoZXJlCj4g YXJlIHR3byBqdXN0IGFzIGFjY2VwdGFibGUgd2F5cyB0byByZXBseS4KPiAKPiAKQWgsIGJ1dCB0 aGUgdGVzdCBjYXNlIGNhbiBiZSBlcXVhbGx5IGdlbmVyaWMgZWl0aGVyIHdheSwgaXQncyBqdXN0 ICAKdGhhdCB0aGlzIHdheSwgaWYgcG9zaXRpb24gaXNuJ3Qgc2V0LCB5b3UgZmlyc3QgaGF2ZSB0 byBkZXRlcm1pbmUgIAp3aGF0IGl0IG91Z2h0IHRvIGJlLgoKCj4gU28gSSBndWVzcyBteSBwcmVm ZXJyZWQgd2F5IG9mIG1ha2luZyBpdCB3b3JrIHdvdWxkIGJlIHRvIG5ldmVyIHNlbmQKPiBjb250 ZXh0IHBvc2l0aW9uIHdpdGggU0VBUkNIIChtb3JlIGltcG9ydGFudCksIGFuZCBtYWtlIGl0Cj4g Y2xpZW50LWNvbmZpZ3VyYWJsZSBmb3IgU09SVCAobGVzcyBpbXBvcnRhbnQpLgoKTm8sIGNhbiBi ZSBtb3JlIGVmZmljaWVudCB0byBzZW5kIHRoZSBwb3NpdGlvbiBmb3IgQUREVE8gb24gU0VBUkNI ZXMuCgpEYXZlLgotLSAKRGF2ZSBDcmlkbGFuZCAtIG1haWx0bzpkYXZlQGNyaWRsYW5kLm5ldCAt IHhtcHA6ZHdkQGRhdmUuY3JpZGxhbmQubmV0CiAgLSBhY2FwOi8vYWNhcC5kYXZlLmNyaWRsYW5k Lm5ldC9ieW93bmVyL3VzZXIvZHdkL2Jvb2ttYXJrcy8KICAtIGh0dHA6Ly9kYXZlLmNyaWRsYW5k Lm5ldC8KSW5mb3Ryb3BlIFBvbHltZXIgLSBBQ0FQLCBJTUFQLCBFU01UUCwgYW5kIExlbW9uYWRl Cl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCmxlbW9uYWRl IG1haWxpbmcgbGlzdApsZW1vbmFkZUBpZXRmLm9yZwpodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL2xlbW9uYWRlClN1cHBsZW1lbnRhbCBXZWIgU2l0ZToKaHR0cDovL3d3dy5z dGFuZGFyZHN0cmFjay5jb20vaWV0Zi9sZW1vbmFkZQ== From lemonade-bounces@ietf.org Thu Jun 5 01:55:39 2008 Return-Path: X-Original-To: lemonade-archive@optimus.ietf.org Delivered-To: ietfarch-lemonade-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AB8153A6C81; Thu, 5 Jun 2008 01:55:39 -0700 (PDT) X-Original-To: lemonade@core3.amsl.com Delivered-To: lemonade@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C82023A6C88 for ; Thu, 5 Jun 2008 01:55:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.524 X-Spam-Level: X-Spam-Status: No, score=-2.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 797M8Y6QIB0F for ; Thu, 5 Jun 2008 01:55:38 -0700 (PDT) Received: from turner.dave.cridland.net (unknown [IPv6:2001:838:378:0:211:9ff:fe2c:e28e]) by core3.amsl.com (Postfix) with ESMTP id 9C3413A6B59 for ; Thu, 5 Jun 2008 01:55:37 -0700 (PDT) Received: from peirce.dave.cridland.net ([217.155.137.61]) by turner.dave.cridland.net (submission) via TCP with ESMTPA id ; Thu, 5 Jun 2008 09:54:52 +0100 X-SMTP-Protocol-Errors: PIPELINING References: <367401715.23521212627157590.JavaMail.root@dogfood.zimbra.com> In-Reply-To: <367401715.23521212627157590.JavaMail.root@dogfood.zimbra.com> MIME-Version: 1.0 Message-Id: <1695.1212656088.244592@peirce.dave.cridland.net> Date: Thu, 05 Jun 2008 09:54:48 +0100 From: Dave Cridland To: Dan Karp Cc: Enhancements to Internet email to support diverse service enivronments , Timo Sirainen Subject: Re: [lemonade] CONTEXT with sequence searches X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org On Thu Jun 5 01:52:37 2008, Dan Karp wrote: > > If a mailbox has 3+ messages and I use: > > > > 1 SEARCH RETURN (UPDATE) 2 > > * ESEARCH (TAG "1") 2 > > 1 OK > > I was under the impression that sequence sets (and UID sets) in > SEARCH/SORT contexts applied only at SEARCH/SORT time. So "2" > in your example would mean "the message at sequence 2 at time of > search", not "whichever message currently occupies sequence 2". > The latter interpretation doesn't seem real-world useful. Yes, the MSNs in the SEARCH or SORT command are evaluated at the time the command is accepted. Not actually stated except in RFC 3501 errata, I believe, so probably needs reiterating here. (UIDs are not specified in this way, but since UIDs are stable at least within a session, these are more predictable). Equally, MSNs used within a response are evaluated at the time of the response. So in your example, you'd see a REMOVEFROM which left the context empty, followed by an EXPUNGE, and that would be all. Confusingly, though, a PARTIAL would actually find a message, since the MSNs would be different. So: C: A01 SEARCH RETURN (ALL UPDATE) 2 S: * ESEARCH (TAG "A01") ALL 2 S: A01 OK Yarp. [...] S: * EXPUNGE 1 [...] S: * ESEARCH (TAG "A01") REMOVEFROM (1 1) S: * EXPUNGE 1 [...] C: A02 SEARCH RETURN (ALL) 2 S: * ESEARCH (TAG "A02") ALL 2 S: A02 OK Yarp. Dave. -- Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@dave.cridland.net - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade _______________________________________________ lemonade mailing list lemonade@ietf.org https://www.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Thu Jun 5 03:24:38 2008 Return-Path: X-Original-To: lemonade-archive@optimus.ietf.org Delivered-To: ietfarch-lemonade-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 420FA28C135; Thu, 5 Jun 2008 03:24:38 -0700 (PDT) X-Original-To: lemonade@core3.amsl.com Delivered-To: lemonade@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 43C3F28C135 for ; Thu, 5 Jun 2008 03:24:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gHCpTFPQQ0UE for ; Thu, 5 Jun 2008 03:24:35 -0700 (PDT) Received: from kalyani.oryx.com (kalyani.oryx.com [195.30.37.30]) by core3.amsl.com (Postfix) with ESMTP id 3BDBA28C102 for ; Thu, 5 Jun 2008 03:24:35 -0700 (PDT) Received: from kalyani.oryx.com (localhost.oryx.com [127.0.0.1]) by kalyani.oryx.com (Postfix) with ESMTP id DAE8C4AC68 for ; Thu, 5 Jun 2008 12:24:37 +0200 (CEST) Received: from 195.30.37.40 (HELO lochnagar.oryx.com) by kalyani.oryx.com with esmtp id 1212661469-75142-3730; Thu, 5 Jun 2008 12:24:29 +0200 Message-Id: Date: Thu, 5 Jun 2008 12:24:01 +0200 From: Arnt Gulbrandsen To: lemonade@ietf.org References: <8B9B8F32-8DEF-40B9-992E-9337FB7AE344@standardstrack.com> <1210951366.9518.654.camel@hurina> <48312F7D.8090103@isode.com> <1211191304.9518.755.camel@hurina> <4835D000.4080808@isode.com> <1211745339.3904.166.camel@hurina> <483BAB35.2080806@isode.com> <1B7D968F-7A77-40FC-AFD6-ADF3C2826822@iki.fi> <484657A5.5070202@isode.com> <1212603466.3904.782.camel@hurina> In-Reply-To: <1212603466.3904.782.camel@hurina> Mime-Version: 1.0 Subject: Re: [lemonade] WGLC NOTIFY X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org Timo Sirainen writes: > I forgot to mention in my previous mail: I don't think it's unreasonable > for an extension to require servers to implement the base IMAP4 > protocol correctly. Untied MessageNew and MessageExpunge handling is > already required for FETCH/STORE/SEARCH handling. How? > If a server has trouble implementing them untied, it's already either > broken or nonoptimal. Peter's code is certainly not optimal. I wish he would stop trying to use MSNs as if they were UIDs. Arnt _______________________________________________ lemonade mailing list lemonade@ietf.org https://www.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Thu Jun 5 03:24:54 2008 Return-Path: X-Original-To: lemonade-archive@optimus.ietf.org Delivered-To: ietfarch-lemonade-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 755D828C179; Thu, 5 Jun 2008 03:24:54 -0700 (PDT) X-Original-To: lemonade@core3.amsl.com Delivered-To: lemonade@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 066DF28C17E for ; Thu, 5 Jun 2008 03:24:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HeLty00H1ZO3 for ; Thu, 5 Jun 2008 03:24:53 -0700 (PDT) Received: from kalyani.oryx.com (kalyani.oryx.com [195.30.37.30]) by core3.amsl.com (Postfix) with ESMTP id 0988128C146 for ; Thu, 5 Jun 2008 03:24:53 -0700 (PDT) Received: from kalyani.oryx.com (localhost.oryx.com [127.0.0.1]) by kalyani.oryx.com (Postfix) with ESMTP id 362264AC6D for ; Thu, 5 Jun 2008 12:24:58 +0200 (CEST) Received: from 195.30.37.40 (HELO lochnagar.oryx.com) by kalyani.oryx.com with esmtp id 1212661470-75142-3731; Thu, 5 Jun 2008 12:24:30 +0200 Message-Id: Date: Thu, 5 Jun 2008 12:24:02 +0200 From: Arnt Gulbrandsen To: lemonade@ietf.org References: <8B9B8F32-8DEF-40B9-992E-9337FB7AE344@standardstrack.com> <1210951366.9518.654.camel@hurina> <48312F7D.8090103@isode.com> <1211191304.9518.755.camel@hurina> <4835D000.4080808@isode.com> <1211745339.3904.166.camel@hurina> <483BAB35.2080806@isode.com> <1B7D968F-7A77-40FC-AFD6-ADF3C2826822@iki.fi> <484657A5.5070202@isode.com> <1212595278.3904.735.camel@hurina> In-Reply-To: <1212595278.3904.735.camel@hurina> Mime-Version: 1.0 Subject: Re: [lemonade] WGLC NOTIFY X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org Timo Sirainen writes: > It took me a while to understand that MSNs can be useful and I don't > want to support an extension that forces clients to stop sending them > in commands. But Notify doesn't do that. What Notify does is different. It lets clients say "tell me about expunges as they happen", "tell me about mailbox creations as they happen" and many other things. If a client uses Notify to say "tell me about expunges as they happen", then that client can't use MSNs in commands any more (except in the sort of corner cases Dave loves). But that limitation is not due to Notify, it's an intrinsic consequence of what the client wants the server to do. Arnt _______________________________________________ lemonade mailing list lemonade@ietf.org https://www.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Thu Jun 5 04:55:15 2008 Return-Path: X-Original-To: lemonade-archive@optimus.ietf.org Delivered-To: ietfarch-lemonade-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8BBC43A6D21; Thu, 5 Jun 2008 04:55:15 -0700 (PDT) X-Original-To: lemonade@core3.amsl.com Delivered-To: lemonade@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7E69E3A6BAA for ; Thu, 5 Jun 2008 04:55:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X6EssfAyLXgo for ; Thu, 5 Jun 2008 04:55:13 -0700 (PDT) Received: from kalyani.oryx.com (kalyani.oryx.com [195.30.37.30]) by core3.amsl.com (Postfix) with ESMTP id 0FA913A6C38 for ; Thu, 5 Jun 2008 04:55:11 -0700 (PDT) Received: from kalyani.oryx.com (localhost.oryx.com [127.0.0.1]) by kalyani.oryx.com (Postfix) with ESMTP id 1CC804AC5B; Thu, 5 Jun 2008 13:55:11 +0200 (CEST) Received: from 195.30.37.40 (HELO lochnagar.oryx.com) by kalyani.oryx.com with esmtp id 1212666902-75142-3770; Thu, 5 Jun 2008 13:55:02 +0200 Message-Id: <9Rniz/zIjg/0TK20yZ9eFA.md5@lochnagar.oryx.com> Date: Thu, 5 Jun 2008 13:54:34 +0200 From: Arnt Gulbrandsen To: lemonade@ietf.org References: <661DF425B4E803C74CE888C8@ninevah.local> <8duStexcACOlvZuw6vhafg.md5@libertango.oryx.com> <3C42FC61AFD98C8C4AEC89E6@ninevah.local> <27B1EB56CB5A3356655C1478@caldav.corp.apple.com> In-Reply-To: <27B1EB56CB5A3356655C1478@caldav.corp.apple.com> Mime-Version: 1.0 Subject: Re: [lemonade] Determining the "has attachment" status of a message X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org I should clarify the results of my test, since it has been misunderstood. I did NOT compress 'fetch 1:* bodystructure' into eight bytes per message. What I did was different. I sent 'fetch 1:* envelope' and 'fetch 1:* (envelope bodystructure)' and computed the size difference. So what my test shows is that if you're fetching To/Cc/From/Subject for a number of messages, then fetching bodystructure USING THE SAME COMMAND adds about eight bytes per message to the compressed size of the response. I haven't measured what happens if separate commands are used, and I dare not predict or guess. And my test only used the mail in my inbox at the time, which may or may not look like anyone else's. Arnt _______________________________________________ lemonade mailing list lemonade@ietf.org https://www.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Thu Jun 5 07:25:51 2008 Return-Path: X-Original-To: lemonade-archive@optimus.ietf.org Delivered-To: ietfarch-lemonade-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 036983A6C83; Thu, 5 Jun 2008 07:25:51 -0700 (PDT) X-Original-To: lemonade@core3.amsl.com Delivered-To: lemonade@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7B00628C122 for ; Thu, 5 Jun 2008 07:25:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.545 X-Spam-Level: X-Spam-Status: No, score=-6.545 tagged_above=-999 required=5 tests=[AWL=0.054, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ey69s2WVGQf1 for ; Thu, 5 Jun 2008 07:25:45 -0700 (PDT) Received: from dovecot.org (dovecot.org [82.118.211.50]) by core3.amsl.com (Postfix) with ESMTP id 8DD383A6C82 for ; Thu, 5 Jun 2008 07:25:45 -0700 (PDT) Received: from [192.168.10.2] (xdsl-177-118.nblnetworks.fi [217.30.177.118]) by dovecot.org (Postfix) with ESMTP id 88D1B16471F8; Thu, 5 Jun 2008 17:25:17 +0300 (EEST) From: Timo Sirainen To: Arnt Gulbrandsen In-Reply-To: References: <8B9B8F32-8DEF-40B9-992E-9337FB7AE344@standardstrack.com> <1210951366.9518.654.camel@hurina> <48312F7D.8090103@isode.com> <1211191304.9518.755.camel@hurina> <4835D000.4080808@isode.com> <1211745339.3904.166.camel@hurina> <483BAB35.2080806@isode.com> <1B7D968F-7A77-40FC-AFD6-ADF3C2826822@iki.fi> <484657A5.5070202@isode.com> <1212595278.3904.735.camel@hurina> Date: Thu, 05 Jun 2008 17:25:16 +0300 Message-Id: <1212675916.3904.858.camel@hurina> Mime-Version: 1.0 X-Mailer: Evolution 2.22.1 Cc: lemonade@ietf.org Subject: Re: [lemonade] WGLC NOTIFY X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2072852186==" Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org --===============2072852186== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-JYGeT6oP0R2ye13P21d2" --=-JYGeT6oP0R2ye13P21d2 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Thu, 2008-06-05 at 12:24 +0200, Arnt Gulbrandsen wrote: > Timo Sirainen writes: > > It took me a while to understand that MSNs can be useful and I don't=20 > > want to support an extension that forces clients to stop sending them=20 > > in commands. >=20 > But Notify doesn't do that. >=20 > What Notify does is different. It lets clients say "tell me about=20 > expunges as they happen", "tell me about mailbox creations as they=20 > happen" and many other things. >=20 > If a client uses Notify to say "tell me about expunges as they happen",=20 > then that client can't use MSNs in commands any more (except in the=20 > sort of corner cases Dave loves). But that limitation is not due to=20 > Notify, it's an intrinsic consequence of what the client wants the=20 > server to do. Currently there's no way to specify the default IMAP server behavior with NOTIFY: Send MessageNew and FlagChange as soon as they happen, but send MessageExpunge only when it's safe to do so. If MessageExpunge wasn't tied to MessageNew I'd be happier. --=-JYGeT6oP0R2ye13P21d2 Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQBIR/dMyUhSUUBViskRArjIAJ9mkAcATyRUCX1wFhcXTwQ/sGWLuQCeLnGJ wvsMZs1S2XKeGHk8qr3EsrQ= =XSzZ -----END PGP SIGNATURE----- --=-JYGeT6oP0R2ye13P21d2-- --===============2072852186== 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://www.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade --===============2072852186==-- From lemonade-bounces@ietf.org Thu Jun 5 08:59:56 2008 Return-Path: X-Original-To: lemonade-archive@optimus.ietf.org Delivered-To: ietfarch-lemonade-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CEB423A685D; Thu, 5 Jun 2008 08:59:55 -0700 (PDT) X-Original-To: lemonade@core3.amsl.com Delivered-To: lemonade@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 39BFC3A693D for ; Thu, 5 Jun 2008 08:59:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.4 X-Spam-Level: X-Spam-Status: No, score=-2.4 tagged_above=-999 required=5 tests=[AWL=0.199, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XfA30ko53m6E for ; Thu, 5 Jun 2008 08:59:47 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id 2695B3A6D26 for ; Thu, 5 Jun 2008 08:57:03 -0700 (PDT) Received: from [172.16.2.157] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Thu, 5 Jun 2008 16:57:09 +0100 Message-ID: <48480CBC.9000805@isode.com> Date: Thu, 05 Jun 2008 16:56:44 +0100 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: Timo Sirainen References: <913883255.3241212549118973.JavaMail.root@dogfood.zimbra.com> <48469A35.2030407@isode.com> <1212595962.3904.737.camel@hurina> In-Reply-To: <1212595962.3904.737.camel@hurina> MIME-Version: 1.0 Cc: IMAP Extensions WG , Enhancements to Internet email to support diverse service enivronments Subject: Re: [lemonade] SORT and CONDSTORE X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org Timo Sirainen wrote: >On Wed, 2008-06-04 at 14:35 +0100, Alexey Melnikov wrote: > > >>Dan Karp wrote: >> >> >>>Quick question: Should >>> >>> A001 SORT (DATE) UTF-8 MODSEQ 500 >>> >>>cause a " (MODSEQ 4551)" to be appended to the SORT result? The >>>SORT extension doesn't indicate it, but it seems as necessary as >>>adding it to the corresponding SEARCH. >>> >>> >>I agree. I can include this into QRESYNC RFC update. >>(I wish we could use ESEARCH response in all cases.) >> >> >And what about THREAD? > > Ok, I can update THREAD response as well. Do we want to extend it, or make the server send another response? _______________________________________________ lemonade mailing list lemonade@ietf.org https://www.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Thu Jun 5 12:59:38 2008 Return-Path: X-Original-To: lemonade-archive@optimus.ietf.org Delivered-To: ietfarch-lemonade-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E0B4328C0E5; Thu, 5 Jun 2008 12:59:38 -0700 (PDT) X-Original-To: lemonade@core3.amsl.com Delivered-To: lemonade@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 29DD628C0E5 for ; Thu, 5 Jun 2008 12:59:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.562 X-Spam-Level: X-Spam-Status: No, score=-2.562 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZugFldW1thQx for ; Thu, 5 Jun 2008 12:59:37 -0700 (PDT) Received: from turner.dave.cridland.net (unknown [IPv6:2001:838:378:0:211:9ff:fe2c:e28e]) by core3.amsl.com (Postfix) with ESMTP id D741028C0E4 for ; Thu, 5 Jun 2008 12:59:36 -0700 (PDT) Received: from peirce.dave.cridland.net ([217.155.137.61]) by turner.dave.cridland.net (submission) via TCP with ESMTPA id for ; Thu, 5 Jun 2008 20:59:25 +0100 X-SMTP-Protocol-Errors: PIPELINING References: <8B9B8F32-8DEF-40B9-992E-9337FB7AE344@standardstrack.com> <1210951366.9518.654.camel@hurina> <48312F7D.8090103@isode.com> <1211191304.9518.755.camel@hurina> <4835D000.4080808@isode.com> <1211745339.3904.166.camel@hurina> <483BAB35.2080806@isode.com> <1B7D968F-7A77-40FC-AFD6-ADF3C2826822@iki.fi> <484657A5.5070202@isode.com> <1212595278.3904.735.camel@hurina> In-Reply-To: MIME-Version: 1.0 Message-Id: <1695.1212695964.870867@peirce.dave.cridland.net> Date: Thu, 05 Jun 2008 20:59:24 +0100 From: Dave Cridland To: Enhancements to Internet email to support diverse service enivronments Subject: Re: [lemonade] WGLC NOTIFY X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org On Thu Jun 5 11:24:02 2008, Arnt Gulbrandsen wrote: > What Notify does is different. It lets clients say "tell me about > expunges as they happen", "tell me about mailbox creations as they > happen" and many other things. > > Actually, not *quite*. It allows these events to occur at any time - the distinction is subtle, I admit. But IMAP4rev1 essentially states that events always happen when they're reported. (It's actually one of the cleverer bits of design there, for all that it causes problems in the expunge case). This means that, in particular, commands are always predictable - in the base specification, at least. > If a client uses Notify to say "tell me about expunges as they > happen", > then that client can't use MSNs in commands any more (except in the > sort of corner cases Dave loves). But that limitation is not due to > Notify, it's an intrinsic consequence of what the client wants the > server to do. Well, the client is now saying it wants events to occur at any time - it's lifting restrictions on them. As such, it can use MSNs, as long as its aware that, being unstable references, they will only become "fixed" when the command is processed, and in the intervening time they may have changed - almost certainly not what's needed. That said, I think many cases will work fine with MSN even so, including cases using FETCH, STORE, etc. Dave. -- Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@dave.cridland.net - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade _______________________________________________ lemonade mailing list lemonade@ietf.org https://www.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Thu Jun 5 13:09:36 2008 Return-Path: X-Original-To: lemonade-archive@optimus.ietf.org Delivered-To: ietfarch-lemonade-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 19BB028C172; Thu, 5 Jun 2008 13:09:36 -0700 (PDT) X-Original-To: lemonade@core3.amsl.com Delivered-To: lemonade@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6C11728C254 for ; Thu, 5 Jun 2008 13:09:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wjizyxqAFt44 for ; Thu, 5 Jun 2008 13:09:33 -0700 (PDT) Received: from kalyani.oryx.com (kalyani.oryx.com [195.30.37.30]) by core3.amsl.com (Postfix) with ESMTP id 9260E28C196 for ; Thu, 5 Jun 2008 13:07:04 -0700 (PDT) Received: from kalyani.oryx.com (localhost.oryx.com [127.0.0.1]) by kalyani.oryx.com (Postfix) with ESMTP id E81264AC68; Thu, 5 Jun 2008 22:07:10 +0200 (CEST) Received: from 195.30.37.40 (HELO lochnagar.oryx.com) by kalyani.oryx.com with esmtp id 1212696421-75142-4048; Thu, 5 Jun 2008 22:07:01 +0200 Message-Id: Date: Thu, 5 Jun 2008 22:06:34 +0200 From: Arnt Gulbrandsen To: lemonade@ietf.org References: <8B9B8F32-8DEF-40B9-992E-9337FB7AE344@standardstrack.com> <1210951366.9518.654.camel@hurina> <48312F7D.8090103@isode.com> <1211191304.9518.755.camel@hurina> <4835D000.4080808@isode.com> <1211745339.3904.166.camel@hurina> <483BAB35.2080806@isode.com> <1B7D968F-7A77-40FC-AFD6-ADF3C2826822@iki.fi> <484657A5.5070202@isode.com> <1212595278.3904.735.camel@hurina> <1212675916.3904.858.camel@hurina> In-Reply-To: <1212675916.3904.858.camel@hurina> Mime-Version: 1.0 Cc: Timo Sirainen Subject: Re: [lemonade] WGLC NOTIFY X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org Timo Sirainen writes: > Currently there's no way to specify the default IMAP server behavior > with NOTIFY: Send MessageNew and FlagChange as soon as they happen, > but send MessageExpunge only when it's safe to do so. That sort of wondered me, but I couldn't find any concrete ill effects even though I tried hard, so I eventually told my intuition "you're wrong too sometimes, so be quiet now". > If MessageExpunge wasn't tied to MessageNew I'd be happier. Yes, so would I. Arnt _______________________________________________ lemonade mailing list lemonade@ietf.org https://www.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Thu Jun 5 13:13:02 2008 Return-Path: X-Original-To: lemonade-archive@optimus.ietf.org Delivered-To: ietfarch-lemonade-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 06A1E3A68E2; Thu, 5 Jun 2008 13:13:02 -0700 (PDT) X-Original-To: lemonade@core3.amsl.com Delivered-To: lemonade@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8EF0C3A68E2 for ; Thu, 5 Jun 2008 13:13:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 99cpQ+bYno04 for ; Thu, 5 Jun 2008 13:12:56 -0700 (PDT) Received: from kalyani.oryx.com (kalyani.oryx.com [195.30.37.30]) by core3.amsl.com (Postfix) with ESMTP id 7BE793A67CE for ; Thu, 5 Jun 2008 13:12:55 -0700 (PDT) Received: from kalyani.oryx.com (localhost.oryx.com [127.0.0.1]) by kalyani.oryx.com (Postfix) with ESMTP id 1F9274AC5A; Thu, 5 Jun 2008 22:13:01 +0200 (CEST) Received: from 195.30.37.40 (HELO lochnagar.oryx.com) by kalyani.oryx.com with esmtp id 1212696772-75142-4052; Thu, 5 Jun 2008 22:12:52 +0200 Message-Id: Date: Thu, 5 Jun 2008 22:12:25 +0200 From: Arnt Gulbrandsen To: lemonade@ietf.org References: <8B9B8F32-8DEF-40B9-992E-9337FB7AE344@standardstrack.com> <1210951366.9518.654.camel@hurina> <48312F7D.8090103@isode.com> <1211191304.9518.755.camel@hurina> <4835D000.4080808@isode.com> <1211745339.3904.166.camel@hurina> <483BAB35.2080806@isode.com> <1B7D968F-7A77-40FC-AFD6-ADF3C2826822@iki.fi> <484657A5.5070202@isode.com> <1212595278.3904.735.camel@hurina> <1212675916.3904.858.camel@hurina> In-Reply-To: Mime-Version: 1.0 Cc: Timo Sirainen Subject: Re: [lemonade] WGLC NOTIFY X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org Arnt Gulbrandsen writes: > That sort of wondered me, I think I wanted ot write "that worried me" and "I wondered about that" and the two expressions mated on the way to the keyboard and produced the offspring you see. Arnt _______________________________________________ lemonade mailing list lemonade@ietf.org https://www.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Thu Jun 5 19:49:42 2008 Return-Path: X-Original-To: lemonade-archive@optimus.ietf.org Delivered-To: ietfarch-lemonade-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 87A093A6968; Thu, 5 Jun 2008 19:49:42 -0700 (PDT) X-Original-To: lemonade@core3.amsl.com Delivered-To: lemonade@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 210443A6968 for ; Thu, 5 Jun 2008 19:49:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.549 X-Spam-Level: X-Spam-Status: No, score=-6.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7qsFBVM6e8J0 for ; Thu, 5 Jun 2008 19:49:40 -0700 (PDT) Received: from dovecot.org (dovecot.org [82.118.211.50]) by core3.amsl.com (Postfix) with ESMTP id DBA503A684A for ; Thu, 5 Jun 2008 19:49:39 -0700 (PDT) Received: from [192.168.10.200] (xdsl-177-118.nblnetworks.fi [217.30.177.118]) by dovecot.org (Postfix) with ESMTP id ECDCCFA8B49 for ; Fri, 6 Jun 2008 05:49:12 +0300 (EEST) Message-Id: From: Timo Sirainen To: lemonade In-Reply-To: <1212675916.3904.858.camel@hurina> Mime-Version: 1.0 (Apple Message framework v924) Date: Fri, 6 Jun 2008 05:49:11 +0300 References: <8B9B8F32-8DEF-40B9-992E-9337FB7AE344@standardstrack.com> <1210951366.9518.654.camel@hurina> <48312F7D.8090103@isode.com> <1211191304.9518.755.camel@hurina> <4835D000.4080808@isode.com> <1211745339.3904.166.camel@hurina> <483BAB35.2080806@isode.com> <1B7D968F-7A77-40FC-AFD6-ADF3C2826822@iki.fi> <484657A5.5070202@isode.com> <1212595278.3904.735.camel@hurina> <1212675916.3904.858.camel@hurina> X-Pgp-Agent: GPGMail d51 (Leopard) X-Mailer: Apple Mail (2.924) Subject: Re: [lemonade] WGLC NOTIFY X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0199802540==" Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============0199802540== Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-23-337634225" Content-Transfer-Encoding: 7bit This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-23-337634225 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit On Jun 5, 2008, at 5:25 PM, Timo Sirainen wrote: > Currently there's no way to specify the default IMAP server behavior > with NOTIFY: Send MessageNew and FlagChange as soon as they happen, > but > send MessageExpunge only when it's safe to do so. If MessageExpunge > wasn't tied to MessageNew I'd be happier. If we assumed nothing was tied together, the current NOTIFY behavior would be: - (MessageNew MessageExpunge FlagChange) : Everything sent immediately - (MessageNew FlagChange) : EXISTS and flags sent immediately, expunges delayed - (MessageNew) : EXISTS sent immediately, expunges delayed, flag changes not sent at all - () : EXISTS and expunges delayed, flag changes not sent at all The closest default IMAP behavior would be (MessageNew FlagChange). Most servers delay sending the changes until a command is started, but that's not required by RFC 3501 so I don't think it matters. Perhaps MessageNew should be always enabled? EXISTS replies can't be disabled entirely in any case and I don't see any benefit in delaying them (if client didn't want to see new events immediately, it wouldn't have called NOTIFY in the first place). With this done and decoupling MessageExpunge there would be no tied events left anymore. That would nicely simplify the specification. --Apple-Mail-23-337634225 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig content-transfer-encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) iEYEARECAAYFAkhIpacACgkQyUhSUUBViskrvACghTrz2A3KCOQwkeQErFAzPzMM eLcAoJ3ChtxaxvasfwXUPDw+/l0AVXNh =dNbb -----END PGP SIGNATURE----- --Apple-Mail-23-337634225-- --===============0199802540== 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://www.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade --===============0199802540==-- From lemonade-bounces@ietf.org Thu Jun 5 19:52:53 2008 Return-Path: X-Original-To: lemonade-archive@optimus.ietf.org Delivered-To: ietfarch-lemonade-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5B8443A6A86; Thu, 5 Jun 2008 19:52:53 -0700 (PDT) X-Original-To: lemonade@core3.amsl.com Delivered-To: lemonade@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 54F6B3A6A86 for ; Thu, 5 Jun 2008 19:52:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.552 X-Spam-Level: X-Spam-Status: No, score=-6.552 tagged_above=-999 required=5 tests=[AWL=0.047, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ltrRUrSvPAFY for ; Thu, 5 Jun 2008 19:52:51 -0700 (PDT) Received: from dovecot.org (dovecot.org [82.118.211.50]) by core3.amsl.com (Postfix) with ESMTP id 3D0743A6968 for ; Thu, 5 Jun 2008 19:52:51 -0700 (PDT) Received: from [192.168.10.200] (xdsl-177-118.nblnetworks.fi [217.30.177.118]) by dovecot.org (Postfix) with ESMTP id 9F12EFA8B49; Fri, 6 Jun 2008 05:52:28 +0300 (EEST) Message-Id: From: Timo Sirainen To: Dave Cridland In-Reply-To: <1212597011.3904.753.camel@hurina> Mime-Version: 1.0 (Apple Message framework v924) Date: Fri, 6 Jun 2008 05:52:27 +0300 References: <1212503709.3904.654.camel@hurina> <1695.1212514262.389177@peirce.dave.cridland.net> <1212597011.3904.753.camel@hurina> X-Pgp-Agent: GPGMail d51 (Leopard) X-Mailer: Apple Mail (2.924) Cc: Enhancements to Internet email to support diverse service enivronments Subject: Re: [lemonade] CONTEXT X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1769420510==" Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============1769420510== Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-24-337829953" Content-Transfer-Encoding: 7bit This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-24-337829953 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit On Jun 4, 2008, at 7:30 PM, Timo Sirainen wrote: > On Tue, 2008-06-03 at 18:31 +0100, Dave Cridland wrote: >> On Tue Jun 3 15:35:09 2008, Timo Sirainen wrote: >>> 1) If ADDTO refers to newly added messages, shouldn't it be >>> required to >>> be sent after EXISTS, just like REMOVETO must be sent before >>> EXPUNGE? So >>> an example session would look like: >>> >>> B01 SEARCH RETURN (UPDATE) ALL >>> * ESEARCH (TAG "B01") 1 >>> B01 OK >>> .. >>> * 1 EXPUNGE >>> * ESEARCH (TAG "B01") UID REMOVEFROM (0 1) >>> * 1 EXISTS >>> * ESEARCH (TAG "B01") UID ADDTO (0 1) >>> >>> >> REMOVEFROM only needs to be sent prior to EXPUNGE if it refers to >> MSNs, since otherwise it is impossible to reference the message to be >> removed from the context - it's not a matter of event ordering, >> both the REMOVEFROM and EXPUNGE occur simultaneously by definition - >> it's a matter of when they can be reported. > > Yes, but I think it's a bit dirty to report sequences that haven't > been > announced yet with EXISTS. It's the same as if server replies: > > * 1 FETCH (FLAGS (\Seen)) > * 1 EXISTS > > Sure the client could understand that the EXISTS probably arrives > soon, > but it complicates the code and error handling. What if the server is > buggy and the EXISTS never arrives? It's more difficult to catch > bugs if > you have to look at future untagged replies to see if something is a > bug > or not. Looks like NOTIFY spec agrees with me: > If a search context is in effect as specified in [CONTEXT], an > ESEARCH ADDTO will also be generated, if appropriate. In this case, > the EXISTS response MUST precede the ESEARCH response. Since it's already specified there, it would be clearer to specify it in CONTEXT as well. --Apple-Mail-24-337829953 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig content-transfer-encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) iEYEARECAAYFAkhIpmsACgkQyUhSUUBViskHTwCfXM1pP2RBlG+H93BVw1aQ2env KeQAnRBPpNxd836EcJR8QU+bDOY6af3n =Ei++ -----END PGP SIGNATURE----- --Apple-Mail-24-337829953-- --===============1769420510== 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://www.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade --===============1769420510==-- From lemonade-bounces@ietf.org Fri Jun 6 14:12:50 2008 Return-Path: X-Original-To: lemonade-archive@optimus.ietf.org Delivered-To: ietfarch-lemonade-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6D3383A6AF8; Fri, 6 Jun 2008 14:12:50 -0700 (PDT) X-Original-To: lemonade@core3.amsl.com Delivered-To: lemonade@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 012073A6C8B for ; Fri, 6 Jun 2008 14:12:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.555 X-Spam-Level: X-Spam-Status: No, score=-6.555 tagged_above=-999 required=5 tests=[AWL=0.044, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LERsPZSyCMUn for ; Fri, 6 Jun 2008 14:12:49 -0700 (PDT) Received: from dovecot.org (dovecot.org [82.118.211.50]) by core3.amsl.com (Postfix) with ESMTP id 3087E3A6AF8 for ; Fri, 6 Jun 2008 14:12:49 -0700 (PDT) Received: from [192.168.10.2] (xdsl-177-118.nblnetworks.fi [217.30.177.118]) by dovecot.org (Postfix) with ESMTP id 44C5116471EC for ; Sat, 7 Jun 2008 00:12:25 +0300 (EEST) From: Timo Sirainen To: lemonade In-Reply-To: <1212503709.3904.654.camel@hurina> References: <1212503709.3904.654.camel@hurina> Date: Sat, 07 Jun 2008 00:12:24 +0300 Message-Id: <1212786744.3904.885.camel@hurina> Mime-Version: 1.0 X-Mailer: Evolution 2.22.1 Subject: Re: [lemonade] CONTEXT X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1761862728==" Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org --===============1761862728== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-v96Yr1TbeZgB56wIICJR" --=-v96Yr1TbeZgB56wIICJR Content-Type: text/plain Content-Transfer-Encoding: quoted-printable > modifier-partial =3D "PARTIAL" SP seq-range > ;; from [IMAP] '*' is allowed in [IMAP] seq-range. I'm guessing it shouldn't be used though? Or if it is allowed, is it returned as '*' or as highest-sequence in ret-data-partial? --=-v96Yr1TbeZgB56wIICJR Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQBISag4yUhSUUBViskRAqRMAJ0WrKshZ4wuz1t/h0yDjSMoELDX6gCeOHfL UU7qQLal0hhjk3fM4x+HUEw= =8m7p -----END PGP SIGNATURE----- --=-v96Yr1TbeZgB56wIICJR-- --===============1761862728== 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://www.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade --===============1761862728==-- From lemonade-bounces@ietf.org Fri Jun 6 14:34:44 2008 Return-Path: X-Original-To: lemonade-archive@optimus.ietf.org Delivered-To: ietfarch-lemonade-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0EC8B3A69EF; Fri, 6 Jun 2008 14:34:44 -0700 (PDT) X-Original-To: lemonade@core3.amsl.com Delivered-To: lemonade@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CBA8D3A69EF for ; Fri, 6 Jun 2008 14:34:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ry2HznuumPrA for ; Fri, 6 Jun 2008 14:34:42 -0700 (PDT) Received: from mta02.zimbra.com (mta02.zimbra.com [77.67.121.28]) by core3.amsl.com (Postfix) with ESMTP id 305453A680D for ; Fri, 6 Jun 2008 14:34:42 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mta02.zimbra.com (Postfix) with ESMTP id B6B22C788CF; Fri, 6 Jun 2008 14:34:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at Received: from mta02.zimbra.com ([127.0.0.1]) by localhost (mta02.zimbra.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xgOPja4RjC4G; Fri, 6 Jun 2008 14:34:45 -0700 (PDT) Received: from dogfood.zimbra.com (dogfood.zimbra.com [10.10.140.44]) by mta02.zimbra.com (Postfix) with ESMTP id 72462C78064; Fri, 6 Jun 2008 14:34:45 -0700 (PDT) Date: Fri, 6 Jun 2008 14:34:52 -0700 (PDT) From: Dan Karp To: Timo Sirainen Message-ID: <1465784202.65971212788092243.JavaMail.root@dogfood.zimbra.com> In-Reply-To: <2080225284.65601212787858660.JavaMail.root@dogfood.zimbra.com> MIME-Version: 1.0 X-Mailer: Zimbra 5.0.7_GA_2362.RHEL4_64 (ZimbraWebClient - FF2.0 (Win)/5.0.7_GA_2362.RHEL4_64) Cc: lemonade Subject: Re: [lemonade] CONTEXT X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org > > modifier-partial = "PARTIAL" SP seq-range > > ;; from [IMAP] > > '*' is allowed in [IMAP] seq-range. I'm guessing it shouldn't be used > though? Or if it is allowed, is it returned as '*' or as > highest-sequence in ret-data-partial? Similarly, returns BAD for message sequence numbers greater than the number of messages in the mailbox. That's contrary to the specified behavior in section 4.4: Where a PARTIAL search return option references results which do not exist, by using a range which starts or ends higher than the current number of results, then the server returns those results which are in the set. This yields a PARTIAL return data item which has, as payload, the original range and a potentially missing set of results which may be shorter than the extent of the range. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Fri Jun 6 14:51:34 2008 Return-Path: X-Original-To: lemonade-archive@optimus.ietf.org Delivered-To: ietfarch-lemonade-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 16BDA28C26D; Fri, 6 Jun 2008 14:51:34 -0700 (PDT) X-Original-To: lemonade@core3.amsl.com Delivered-To: lemonade@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 21A7628C269 for ; Fri, 6 Jun 2008 14:51:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.558 X-Spam-Level: X-Spam-Status: No, score=-6.558 tagged_above=-999 required=5 tests=[AWL=0.041, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aNuuNduSRHtN for ; Fri, 6 Jun 2008 14:51:32 -0700 (PDT) Received: from dovecot.org (dovecot.org [82.118.211.50]) by core3.amsl.com (Postfix) with ESMTP id 3188C28C24D for ; Fri, 6 Jun 2008 14:51:32 -0700 (PDT) Received: from [192.168.10.2] (xdsl-177-118.nblnetworks.fi [217.30.177.118]) by dovecot.org (Postfix) with ESMTP id 10B3E16471EC; Sat, 7 Jun 2008 00:51:12 +0300 (EEST) From: Timo Sirainen To: Dan Karp In-Reply-To: <1465784202.65971212788092243.JavaMail.root@dogfood.zimbra.com> References: <1465784202.65971212788092243.JavaMail.root@dogfood.zimbra.com> Date: Sat, 07 Jun 2008 00:51:11 +0300 Message-Id: <1212789071.3904.891.camel@hurina> Mime-Version: 1.0 X-Mailer: Evolution 2.22.1 Cc: lemonade Subject: Re: [lemonade] CONTEXT X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0578025783==" Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org --===============0578025783== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-Rj1BQunt35EDwcZ+aN6I" --=-Rj1BQunt35EDwcZ+aN6I Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Fri, 2008-06-06 at 14:34 -0700, Dan Karp wrote: > > > modifier-partial =3D "PARTIAL" SP seq-range > > > ;; from [IMAP] > >=20 > > '*' is allowed in [IMAP] seq-range. I'm guessing it shouldn't be used > > though? Or if it is allowed, is it returned as '*' or as > > highest-sequence in ret-data-partial? >=20 > Similarly, returns BAD for message sequence numbers greater > than the number of messages in the mailbox. seq-range is specified to contain either message sequences or UIDs, but modifier-partial contains "search-sequences" which is neither of them. So I guess it should instead be: modifier-partial =3D "PARTIAL" SP nz-number ":" nz-number ;; a) First nz-number <=3D second nz-number ;; b) Ordering between nz-numbers doesn't matter I don't really care if a) or b) is used. --=-Rj1BQunt35EDwcZ+aN6I Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQBISbFPyUhSUUBViskRAuG1AJ4zQGcrW7hmRdeXB9YYBPBxBojY0QCfdMP5 qcRG8tqFy0lpQRHOgtT/Oyg= =FIC8 -----END PGP SIGNATURE----- --=-Rj1BQunt35EDwcZ+aN6I-- --===============0578025783== 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://www.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade --===============0578025783==-- From lemonade-bounces@ietf.org Sun Jun 8 19:01:55 2008 Return-Path: X-Original-To: lemonade-archive@optimus.ietf.org Delivered-To: ietfarch-lemonade-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DF43B3A6C28; Sun, 8 Jun 2008 19:01:55 -0700 (PDT) X-Original-To: lemonade@core3.amsl.com Delivered-To: lemonade@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B9A393A6906 for ; Sun, 8 Jun 2008 19:01:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.816 X-Spam-Level: X-Spam-Status: No, score=-5.816 tagged_above=-999 required=5 tests=[AWL=-0.706, BAYES_05=-1.11, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xNFz4EdClyse for ; Sun, 8 Jun 2008 19:01:54 -0700 (PDT) Received: from dovecot.org (dovecot.org [82.118.211.50]) by core3.amsl.com (Postfix) with ESMTP id E71453A6C24 for ; Sun, 8 Jun 2008 19:01:53 -0700 (PDT) Received: from [192.168.10.2] (xdsl-177-118.nblnetworks.fi [217.30.177.118]) by dovecot.org (Postfix) with ESMTP id 02D69FA8A84 for ; Mon, 9 Jun 2008 05:01:36 +0300 (EEST) From: Timo Sirainen To: lemonade Date: Mon, 09 Jun 2008 05:01:36 +0300 Message-Id: <1212976896.3904.912.camel@hurina> Mime-Version: 1.0 X-Mailer: Evolution 2.22.1 Subject: [lemonade] CONDSTORE and EXAMINE X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1495180467==" Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org --===============1495180467== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-WDfVLy188O0/hiMuqXMI" --=-WDfVLy188O0/hiMuqXMI Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Let's assume that the server implements modifiable session-only flags for EXAMINEd mailboxes and read-only mailboxes (as I suppose all servers should, but I haven't bothered). When using such a server and EXAMINEd/read-only mailbox, should STORE UNCHANGEDSINCE: a) Always fail with "NO Read-only mailbox" b) Like a), but [MODIFIED] properly set. c) Update the session-only flags somehow? --=-WDfVLy188O0/hiMuqXMI Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQBITI8AyUhSUUBViskRApwQAJoC2RuAyUraLJqHygrqTg+xj99i7gCgo4lO kZisHMn8DN+iN4mHU9dy9iQ= =+O/6 -----END PGP SIGNATURE----- --=-WDfVLy188O0/hiMuqXMI-- --===============1495180467== 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://www.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade --===============1495180467==-- From lemonade-bounces@ietf.org Mon Jun 9 02:10:35 2008 Return-Path: X-Original-To: lemonade-archive@optimus.ietf.org Delivered-To: ietfarch-lemonade-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 33DA73A6ABD; Mon, 9 Jun 2008 02:10:35 -0700 (PDT) X-Original-To: lemonade@core3.amsl.com Delivered-To: lemonade@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 371623A6ABD for ; Mon, 9 Jun 2008 02:10:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a3mYAbVpoaVT for ; Mon, 9 Jun 2008 02:10:30 -0700 (PDT) Received: from kalyani.oryx.com (kalyani.oryx.com [195.30.37.30]) by core3.amsl.com (Postfix) with ESMTP id D50F03A6910 for ; Mon, 9 Jun 2008 02:10:29 -0700 (PDT) Received: from kalyani.oryx.com (localhost.oryx.com [127.0.0.1]) by kalyani.oryx.com (Postfix) with ESMTP id 27F354AC72 for ; Mon, 9 Jun 2008 11:10:47 +0200 (CEST) Received: from 195.30.37.40 (HELO lochnagar.oryx.com) by kalyani.oryx.com with esmtp id 1213002626-75142-5420; Mon, 9 Jun 2008 11:10:26 +0200 Message-Id: Date: Mon, 9 Jun 2008 11:09:43 +0200 From: Arnt Gulbrandsen To: lemonade@ietf.org Mime-Version: 1.0 Subject: [lemonade] notify and subscriptions X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org I'm working on my implementation. The hard stuff is done, lots of details are left. One such detail is subscriptionchange. Does subscriptionchange cover all subscription changes on the mailboxes specifed, or just the user's own subscription changes? I'm not sure which behaviour is most desirable. Arnt _______________________________________________ lemonade mailing list lemonade@ietf.org https://www.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Mon Jun 9 02:30:33 2008 Return-Path: X-Original-To: lemonade-archive@optimus.ietf.org Delivered-To: ietfarch-lemonade-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2359B3A690F; Mon, 9 Jun 2008 02:30:33 -0700 (PDT) X-Original-To: lemonade@core3.amsl.com Delivered-To: lemonade@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CCEF43A6823 for ; Mon, 9 Jun 2008 02:30:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TQeOMzO9qrtS for ; Mon, 9 Jun 2008 02:30:31 -0700 (PDT) Received: from kalyani.oryx.com (kalyani.oryx.com [195.30.37.30]) by core3.amsl.com (Postfix) with ESMTP id BF74B3A690F for ; Mon, 9 Jun 2008 02:30:29 -0700 (PDT) Received: from kalyani.oryx.com (localhost.oryx.com [127.0.0.1]) by kalyani.oryx.com (Postfix) with ESMTP id 7BF304AC64 for ; Mon, 9 Jun 2008 11:30:47 +0200 (CEST) Received: from 195.30.37.40 (HELO lochnagar.oryx.com) by kalyani.oryx.com with esmtp id 1213003838-75142-5438; Mon, 9 Jun 2008 11:30:38 +0200 Message-Id: Date: Mon, 9 Jun 2008 11:29:54 +0200 From: Arnt Gulbrandsen To: lemonade@ietf.org References: <1212976896.3904.912.camel@hurina> In-Reply-To: <1212976896.3904.912.camel@hurina> Mime-Version: 1.0 Subject: Re: [lemonade] CONDSTORE and EXAMINE X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org Timo Sirainen writes: > Let's assume that the server implements modifiable session-only flags > for EXAMINEd mailboxes and read-only mailboxes (as I suppose all > servers should, but I haven't bothered). When using such a server and > EXAMINEd/read-only mailbox, should STORE UNCHANGEDSINCE: > > a) Always fail with "NO Read-only mailbox" IMO noone should expect more of you than that. My regular rant, for those who haven't heard or have forgotten: Computers and software exist to help people. Helping people access their mail via low-bandwith connections is a clear benefit to many people, so Lemonade is a good thing. But picking a particular combination of error messages doesn't help people. In this case I think you have three things to report, and you can report either one or two of them. Detecting and reporting errors is good, since it helps prevent errors from unpleasant consequences. But it's only helpful in a double-negative sense: Prevents undesirable actions. When an IMAP server carries out a command, that's helpful in an entirely plain way. It's also a much more common case. We're better off if we spent most of our time on making the plainly helpful features work well and interoperably. Errors just have to be prevented, it's not so important exactly how. Report any of the three. Arnt _______________________________________________ lemonade mailing list lemonade@ietf.org https://www.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Mon Jun 9 02:30:57 2008 Return-Path: X-Original-To: lemonade-archive@optimus.ietf.org Delivered-To: ietfarch-lemonade-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6019628C0FA; Mon, 9 Jun 2008 02:30:57 -0700 (PDT) X-Original-To: lemonade@core3.amsl.com Delivered-To: lemonade@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7F7E93A6AEB for ; Mon, 9 Jun 2008 02:30:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.454 X-Spam-Level: X-Spam-Status: No, score=-2.454 tagged_above=-999 required=5 tests=[AWL=0.145, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qHiMCksdGQcj for ; Mon, 9 Jun 2008 02:30:55 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id F2AA63A6A4F for ; Mon, 9 Jun 2008 02:30:54 -0700 (PDT) Received: from [192.168.0.2] ((unknown) [62.3.217.253]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Mon, 9 Jun 2008 10:31:12 +0100 X-SMTP-Protocol-Errors: NORDNS Message-ID: <484CF85E.5050100@isode.com> Date: Mon, 09 Jun 2008 10:31:10 +0100 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: Timo Sirainen References: <1212503709.3904.654.camel@hurina> <1212786744.3904.885.camel@hurina> In-Reply-To: <1212786744.3904.885.camel@hurina> MIME-Version: 1.0 Cc: lemonade Subject: Re: [lemonade] CONTEXT X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org Timo Sirainen wrote: >>modifier-partial = "PARTIAL" SP seq-range >> ;; from [IMAP] >> >> >'*' is allowed in [IMAP] seq-range. I'm guessing it shouldn't be used >though? Or if it is allowed, is it returned as '*' or as >highest-sequence in ret-data-partial? > > I don't think "*" should be allowed, Isode's implementation doesn't accept it. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Mon Jun 9 02:37:00 2008 Return-Path: X-Original-To: lemonade-archive@optimus.ietf.org Delivered-To: ietfarch-lemonade-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DDB0D3A6AEB; Mon, 9 Jun 2008 02:37:00 -0700 (PDT) X-Original-To: lemonade@core3.amsl.com Delivered-To: lemonade@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7A2BD3A690F for ; Mon, 9 Jun 2008 02:36:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.466 X-Spam-Level: X-Spam-Status: No, score=-2.466 tagged_above=-999 required=5 tests=[AWL=0.133, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8YEPYyrhaapE for ; Mon, 9 Jun 2008 02:36:58 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id 626ED3A6AEB for ; Mon, 9 Jun 2008 02:36:58 -0700 (PDT) Received: from [192.168.0.2] ((unknown) [62.3.217.253]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Mon, 9 Jun 2008 10:37:16 +0100 X-SMTP-Protocol-Errors: NORDNS Message-ID: <484CF9CA.6030402@isode.com> Date: Mon, 09 Jun 2008 10:37:14 +0100 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: Timo Sirainen References: <1465784202.65971212788092243.JavaMail.root@dogfood.zimbra.com> <1212789071.3904.891.camel@hurina> In-Reply-To: <1212789071.3904.891.camel@hurina> MIME-Version: 1.0 Cc: lemonade Subject: Re: [lemonade] CONTEXT X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org Timo Sirainen wrote: >On Fri, 2008-06-06 at 14:34 -0700, Dan Karp wrote: > > >>>>modifier-partial = "PARTIAL" SP seq-range >>>> ;; from [IMAP] >>>> >>>> >>>'*' is allowed in [IMAP] seq-range. I'm guessing it shouldn't be used >>>though? Or if it is allowed, is it returned as '*' or as >>>highest-sequence in ret-data-partial? >>> >>> >>Similarly, returns BAD for message sequence numbers greater >>than the number of messages in the mailbox. >> >> >seq-range is specified to contain either message sequences or UIDs, but >modifier-partial contains "search-sequences" which is neither of them. >So I guess it should instead be: > >modifier-partial = "PARTIAL" SP nz-number ":" nz-number > ;; a) First nz-number <= second nz-number > ;; b) Ordering between nz-numbers doesn't matter > >I don't really care if a) or b) is used. > > (b), to make it more or less consistent with ranges. Similarly, ret-data-partial should also be updated: OLD: ret-data-partial = "PARTIAL" SP "(" seq-range SP partial-results ")" ;; is the requested range. ;; from [IMAP] NEW: ret-data-partial = "PARTIAL" SP "(" partial-range SP partial-results ")" ;; is the requested range. partial-range = nz-number ":" nz-number ;; A range 500:400 is the same as 400:500 _______________________________________________ lemonade mailing list lemonade@ietf.org https://www.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Mon Jun 9 03:39:42 2008 Return-Path: X-Original-To: lemonade-archive@optimus.ietf.org Delivered-To: ietfarch-lemonade-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AE4373A6892; Mon, 9 Jun 2008 03:39:42 -0700 (PDT) X-Original-To: lemonade@core3.amsl.com Delivered-To: lemonade@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 351813A6A4A for ; Mon, 9 Jun 2008 03:39:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.485 X-Spam-Level: X-Spam-Status: No, score=-2.485 tagged_above=-999 required=5 tests=[AWL=0.114, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sEE6Y4CYWjOE for ; Mon, 9 Jun 2008 03:39:40 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id C28313A6823 for ; Mon, 9 Jun 2008 03:39:39 -0700 (PDT) Received: from [192.168.0.2] ((unknown) [62.3.217.253]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Mon, 9 Jun 2008 11:39:57 +0100 X-SMTP-Protocol-Errors: NORDNS Message-ID: <484D0878.3000506@isode.com> Date: Mon, 09 Jun 2008 11:39:52 +0100 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: Arnt Gulbrandsen References: In-Reply-To: MIME-Version: 1.0 Cc: lemonade@ietf.org Subject: Re: [lemonade] notify and subscriptions X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org Arnt Gulbrandsen wrote: >I'm working on my implementation. The hard stuff is done, lots of >details are left. > >One such detail is subscriptionchange. Does subscriptionchange cover all >subscription changes on the mailboxes specifed, or just the user's own >subscription changes? > I think the latter. There is currently no way in IMAP to learn about other user's subscriptions to a mailbox and I can't think of a reason why this would be needed. >I'm not sure which behaviour is most desirable. > > _______________________________________________ lemonade mailing list lemonade@ietf.org https://www.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Mon Jun 9 12:05:46 2008 Return-Path: X-Original-To: lemonade-archive@optimus.ietf.org Delivered-To: ietfarch-lemonade-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 00C143A69E6; Mon, 9 Jun 2008 12:05:46 -0700 (PDT) X-Original-To: lemonade@core3.amsl.com Delivered-To: lemonade@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 09CB03A6BE8 for ; Mon, 9 Jun 2008 12:05:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dpl8T3vDNcuX for ; Mon, 9 Jun 2008 12:05:44 -0700 (PDT) Received: from kalyani.oryx.com (kalyani.oryx.com [195.30.37.30]) by core3.amsl.com (Postfix) with ESMTP id C944B3A69E6 for ; Mon, 9 Jun 2008 12:05:43 -0700 (PDT) Received: from kalyani.oryx.com (localhost.oryx.com [127.0.0.1]) by kalyani.oryx.com (Postfix) with ESMTP id 9E70B4AC5B for ; Mon, 9 Jun 2008 21:06:02 +0200 (CEST) Received: from 195.30.37.40 (HELO lochnagar.oryx.com) by kalyani.oryx.com with esmtp id 1213038362-19054-117; Mon, 9 Jun 2008 21:06:02 +0200 Message-Id: <7pXfNmohmSTHlVO40TP1qw.md5@lochnagar.oryx.com> Date: Mon, 9 Jun 2008 21:05:14 +0200 From: Arnt Gulbrandsen To: lemonade@ietf.org References: <484D0878.3000506@isode.com> In-Reply-To: <484D0878.3000506@isode.com> Mime-Version: 1.0 Subject: Re: [lemonade] notify and subscriptions X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org Alexey Melnikov writes: > Arnt Gulbrandsen wrote: >> One such detail is subscriptionchange. Does subscriptionchange cover >> all subscription changes on the mailboxes specifed, or just the >> user's own subscription changes? > > I think the latter. There is currently no way in IMAP to learn about > other user's subscriptions to a mailbox and I can't think of a reason > why this would be needed. Fine with me. That's what I'll implement, then. Arnt _______________________________________________ lemonade mailing list lemonade@ietf.org https://www.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Mon Jun 9 17:25:56 2008 Return-Path: X-Original-To: lemonade-archive@optimus.ietf.org Delivered-To: ietfarch-lemonade-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 18AB33A6864; Mon, 9 Jun 2008 17:25:56 -0700 (PDT) X-Original-To: lemonade@core3.amsl.com Delivered-To: lemonade@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 179153A6864 for ; Mon, 9 Jun 2008 17:25:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AcHPCOsTFcsI for ; Mon, 9 Jun 2008 17:25:51 -0700 (PDT) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by core3.amsl.com (Postfix) with ESMTP id 6777B3A6765 for ; Mon, 9 Jun 2008 17:25:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=randy@qualcomm.com; q=dns/txt; s=qcdkim; t=1213057572; x=1244593572; h=message-id:in-reply-to:references:x-mailer: x-message-flag:date:to:from:subject:cc:content-type: x-random-sig-tag:x-ironport-av; z=Message-Id:=20 |In-Reply-To:=20<48206629.5020305@isode.com>|References: =20=0D=0A=20<48206629.502 0305@isode.com>|X-Mailer:=20Eudora=20for=20Mac=20OS=20X |X-message-flag:=20Warning:=20Outlook=20in=20use.=20=20Up grade=20to=20Eudora:=20|Date:=20Mo n,=209=20Jun=202008=2017:25:57=20-0700|To:=20Alexey=20Mel nikov=20,=0D=0A=20=20=20=20=20 =20=20=20Randall=20Gellens=20|From: =20Randall=20Gellens=20|Subject:=20Re :=20[lemonade]=20WGLC=20Notifications|Cc:=20lemonade@ietf .org|Content-Type:=20text/plain=3B=20charset=3D"us-ascii" =20=3B=20format=3D"flowed"|X-Random-Sig-Tag:=201.0b28 |X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5200,2160,5313"=3B=20 a=3D"3797591"; bh=HRNxriV5mbiw6RbPm+We6FQweBWXv/XjFqwosTfxNRI=; b=pu869/19TEcvZzKEZncUVr1U4YQ0renYKOM2VhS9Vlk7hO3NVRXLmwXI HVj5CWBmpTfW/8yrTkI3Dm3vVeFl1G2WO7Kv56gprYICOytMbpjPwmXJV 75YwO9FRrxsmuMQeGZqnAaMC2sergetCRcQFthXZ6EDXX9Qyb5ylXflmy g=; X-IronPort-AV: E=McAfee;i="5200,2160,5313"; a="3797591" Received: from pdmz-ns-mip.qualcomm.com (HELO numenor.qualcomm.com) ([199.106.114.10]) by wolverine01.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 09 Jun 2008 17:26:11 -0700 Received: from msgtransport05.qualcomm.com (msgtransport05.qualcomm.com [129.46.61.150]) by numenor.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id m5A0QBZf011880 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 9 Jun 2008 17:26:11 -0700 Received: from [192.168.1.13] (loud.qualcomm.com [129.46.72.21]) by msgtransport05.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id m5A0Q6PT029388; Mon, 9 Jun 2008 17:26:09 -0700 Mime-Version: 1.0 Message-Id: In-Reply-To: <48206629.5020305@isode.com> References: <48206629.5020305@isode.com> X-Mailer: Eudora for Mac OS X X-message-flag: Warning: Outlook in use. Upgrade to Eudora: Date: Mon, 9 Jun 2008 17:25:57 -0700 To: Alexey Melnikov , Randall Gellens From: Randall Gellens Mime-Version: 1.0 X-Random-Sig-Tag: 1.0b28 Cc: lemonade@ietf.org Subject: Re: [lemonade] WGLC Notifications X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org Woops! Sprry for not sending this earlier. At 3:07 PM +0100 5/6/08, Alexey Melnikov wrote: > Eric Burger wrote: > >>Work Group Last Call for Lemonade Notifications Architecture, >>http://tools.ietf.org/html/draft-ietf-lemonade-notifications-08 >>starts now and ends 5 May 2008. >> > The draft is in much better shape now. > > Some comments below: > >> * NF and DF: When internal to the mail store, these are >> typically implemented using Sieve and hence a Sieve management > > protocol is used for client modifications. See [IMAP-SIEVE] and > > [MANAGE-SIEVE] for more information. When the NF is within a >> notification server, it is out of scope of Lemonade. > > I don't think [IMAP-SIEVE] is relevant in case of NF or DF. > Unless NF is invoked on message flag changes, etc. I'm happy deleting the reference to IMAP-SIEVE, however, if a client is only interested in some mailboxes, rather than having a main Sieve script send notifications for all new mail, it might be better to have a per-mailbox Sieve script send notifications. How about changing See [IMAP-SIEVE] and [MANAGE-SIEVE] for more information. to See [MANAGE-SIEVE] for more information. Per-mailbox notifications might be implemented using a per-mailbox Sieve script, for example, [IMAP-SIEVE]. > > Note that when implementing DF using Sieve, the 'enotify' >> [SIEVE-NOTIFY] and 'variables' [SIEVE-VARIABLES] Sieve extensions >> are needed. > > If NF is generating notifications on mail delivery, than 'enotify' + > 'variables' is also needed there. > If NF is generating notifications both on mail delivery and IMAP events, > then 'enotify' + 'variables' are *only* needed in NF. I think I should change this to: Note that when implementing DF or NF using Sieve, the 'enotify' [SIEVE-NOTIFY] and likely the 'variables' [SIEVE-VARIABLES] Sieve extensions might be needed. And move it to be above the line that starts "The filters are manageable" (since logically this belongs with the earlier text block). > > 4. Push Email >> >> A good user experience of "push email" requires that when >> "interesting" events occur in the mail store, the client is informed >> so that it can connect and resynchronize. The Lemonade Profile >> [LEMONADE-PROFILE] contains more information, especially in Section >> 4.1.2. > > I can't find section 4.1.2 in draft-ietf-lemonade-profile-bis-08.txt. > /* > */ I suppose the text moved in a prior revision. I think this should be changed to "External Notifications". -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly-selected tag: --------------- Genetics explains why you look like your father, and if you don't, why you should. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Mon Jun 9 17:26:07 2008 Return-Path: X-Original-To: lemonade-archive@optimus.ietf.org Delivered-To: ietfarch-lemonade-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 636473A6A0C; Mon, 9 Jun 2008 17:26:07 -0700 (PDT) X-Original-To: lemonade@core3.amsl.com Delivered-To: lemonade@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 82AB73A6A33 for ; Mon, 9 Jun 2008 17:26:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d7CSgMsqlWuq for ; Mon, 9 Jun 2008 17:26:05 -0700 (PDT) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by core3.amsl.com (Postfix) with ESMTP id 882403A6765 for ; Mon, 9 Jun 2008 17:26:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=randy@qualcomm.com; q=dns/txt; s=qcdkim; t=1213057586; x=1244593586; h=message-id:in-reply-to:references:x-mailer: x-message-flag:date:to:from:subject:cc:content-type: x-random-sig-tag:x-ironport-av; z=Message-Id:=20 |In-Reply-To:=20<42D8937C-4FC9-4CCE-95B1-A0219C019888@sta ndardstrack.com>|References:=20=0D=0A=20<48206629.5020305@isode.com>=0D=0A=20<42D8 937C-4FC9-4CCE-95B1-A0219C019888@standardstrack.com> |X-Mailer:=20Eudora=20for=20Mac=20OS=20X|X-message-flag: =20Warning:=20Outlook=20in=20use.=20=20Upgrade=20to=20Eud ora:=20|Date:=20Mon,=209=20Jun=202 008=2017:26:01=20-0700|To:=20Eric=20Burger=20,=0D=0A=20=20=20=20=20=20=20=20Alexey=20M elnikov=20,=0D=0A=20=20=20=20 =20=20=20=20Randall=20Gellens=20 |From:=20Randall=20Gellens=20 |Subject:=20Re:=20[lemonade]=20WGLC=20Notifications|Cc: =20lemonade@ietf.org|Content-Type:=20text/plain=3B=20char set=3D"us-ascii"=20=3B=20format=3D"flowed" |X-Random-Sig-Tag:=201.0b28|X-IronPort-AV:=20E=3DMcAfee =3Bi=3D"5200,2160,5313"=3B=20a=3D"3623942"; bh=MA16Z+S5mOtYwIeffAnrE8FGXCgHUj8Rq/BcDI2SEDA=; b=tPlokhqctQ4WDUVoVJmplkTvoDLlnzTHymPirDZV8WNz0sIWQwAJ/Rty Uy+j12/flqUUwHffd0qg1VItCKJiq3NQyP0ySBok6Noh+H1FCcc5/tZLx aaw9w1VO24dcIjgiYAmeL0NxWR0qV7nGGTjNo0N5yGzlSciE+tE6i6JRJ E=; X-IronPort-AV: E=McAfee;i="5200,2160,5313"; a="3623942" Received: from pdmz-ns-mip.qualcomm.com (HELO numenor.qualcomm.com) ([199.106.114.10]) by wolverine02.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 09 Jun 2008 17:26:26 -0700 Received: from msgtransport05.qualcomm.com (msgtransport05.qualcomm.com [129.46.61.150]) by numenor.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id m5A0QPpS011908 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 9 Jun 2008 17:26:25 -0700 Received: from [192.168.1.13] (loud.qualcomm.com [129.46.72.21]) by msgtransport05.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id m5A0Q6PV029388; Mon, 9 Jun 2008 17:26:22 -0700 Mime-Version: 1.0 Message-Id: In-Reply-To: <42D8937C-4FC9-4CCE-95B1-A0219C019888@standardstrack.com> References: <48206629.5020305@isode.com> <42D8937C-4FC9-4CCE-95B1-A0219C019888@standardstrack.com> X-Mailer: Eudora for Mac OS X X-message-flag: Warning: Outlook in use. Upgrade to Eudora: Date: Mon, 9 Jun 2008 17:26:01 -0700 To: Eric Burger , Alexey Melnikov , Randall Gellens From: Randall Gellens Mime-Version: 1.0 X-Random-Sig-Tag: 1.0b28 Cc: lemonade@ietf.org Subject: Re: [lemonade] WGLC Notifications X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org At 8:16 AM -0400 5/16/08, Eric Burger wrote: > Nit: When I read this, I had no idea what "it" is. Here is my guess. > > Section 5.2 > > OLD > > notification system; it then becomes > > NEW > > notification system. Thus the security relationship then becomes Yes, this is better. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly-selected tag: --------------- Eleanor Rigby Sits at the keyboard and waits for a line on the screen Lives in a dream Waits for a signal, finding some code that will make the machine do some thing, What is it for? All the lonely users, where do they all come from? All the lonely users, why does it take so long? _______________________________________________ lemonade mailing list lemonade@ietf.org https://www.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Mon Jun 9 17:27:04 2008 Return-Path: X-Original-To: lemonade-archive@optimus.ietf.org Delivered-To: ietfarch-lemonade-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D27803A6A0C; Mon, 9 Jun 2008 17:27:04 -0700 (PDT) X-Original-To: lemonade@core3.amsl.com Delivered-To: lemonade@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AF3043A6A0C for ; Mon, 9 Jun 2008 17:27:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ymcVSoeEnSe8 for ; Mon, 9 Jun 2008 17:27:02 -0700 (PDT) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by core3.amsl.com (Postfix) with ESMTP id 8B4CE3A6765 for ; Mon, 9 Jun 2008 17:27:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=randy@qualcomm.com; q=dns/txt; s=qcdkim; t=1213057643; x=1244593643; h=message-id:in-reply-to:references:x-mailer: x-message-flag:date:to:from:subject:cc:content-type: x-random-sig-tag:x-ironport-av; z=Message-Id:=20 |In-Reply-To:=20<42D8937C-4FC9-4CCE-95B1-A0219C019888@sta ndardstrack.com>|References:=20=0D=0A=20<48206629.5020305@isode.com>=0D=0A=20<42D8 937C-4FC9-4CCE-95B1-A0219C019888@standardstrack.com> |X-Mailer:=20Eudora=20for=20Mac=20OS=20X|X-message-flag: =20Warning:=20Outlook=20in=20use.=20=20Upgrade=20to=20Eud ora:=20|Date:=20Mon,=209=20Jun=202 008=2017:26:58=20-0700|To:=20Eric=20Burger=20,=0D=0A=20=20=20=20=20=20=20=20Alexey=20M elnikov=20,=0D=0A=20=20=20=20 =20=20=20=20Randall=20Gellens=20 |From:=20Randall=20Gellens=20 |Subject:=20Re:=20[lemonade]=20WGLC=20Notifications|Cc: =20lemonade@ietf.org|Content-Type:=20text/plain=3B=20char set=3D"us-ascii"=20=3B=20format=3D"flowed" |X-Random-Sig-Tag:=201.0b28|X-IronPort-AV:=20E=3DMcAfee =3Bi=3D"5200,2160,5313"=3B=20a=3D"3797615"; bh=jt8a6XW0YD2seA5+v4HuG90NPtuKeH45xxdFx0Dkz/w=; b=sTwG56B0xWJK19DJuOybTB8PDoekma/RUF4Qngvd2xy0wVBySqy/CjxH w+lhBFZcGYgSbaz8/eGUZQu3hUValMzURANaDpBEWQJJYJfJ40qjiqSbB vvPp+0zzSBtUWSvLepXOg4eyaEaxe6Gve2y/OEYZftohMy+eK30gkqmWe Q=; X-IronPort-AV: E=McAfee;i="5200,2160,5313"; a="3797615" Received: from pdmz-ns-mip.qualcomm.com (HELO numenor.qualcomm.com) ([199.106.114.10]) by wolverine01.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 09 Jun 2008 17:27:23 -0700 Received: from msgtransport04.qualcomm.com (msgtransport04.qualcomm.com [129.46.61.156]) by numenor.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id m5A0RMYt012008 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 9 Jun 2008 17:27:22 -0700 Received: from [192.168.1.13] (loud.qualcomm.com [129.46.72.21]) by msgtransport04.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id m5A0RI0K020710; Mon, 9 Jun 2008 17:27:21 -0700 Mime-Version: 1.0 Message-Id: In-Reply-To: <42D8937C-4FC9-4CCE-95B1-A0219C019888@standardstrack.com> References: <48206629.5020305@isode.com> <42D8937C-4FC9-4CCE-95B1-A0219C019888@standardstrack.com> X-Mailer: Eudora for Mac OS X X-message-flag: Warning: Outlook in use. Upgrade to Eudora: Date: Mon, 9 Jun 2008 17:26:58 -0700 To: Eric Burger , Alexey Melnikov , Randall Gellens From: Randall Gellens Mime-Version: 1.0 X-Random-Sig-Tag: 1.0b28 Cc: lemonade@ietf.org Subject: Re: [lemonade] WGLC Notifications X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org At 8:16 AM -0400 5/16/08, Eric Burger wrote: > I have written up the shepherd document. Is this OK? Sorry for being dense, but where is the shepherd document? -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly-selected tag: --------------- The early bird catches the worm, but what does the early worm get? --Randall Gellens _______________________________________________ lemonade mailing list lemonade@ietf.org https://www.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Tue Jun 10 19:12:12 2008 Return-Path: X-Original-To: lemonade-archive@optimus.ietf.org Delivered-To: ietfarch-lemonade-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3F7B03A67AF; Tue, 10 Jun 2008 19:12:12 -0700 (PDT) X-Original-To: lemonade@core3.amsl.com Delivered-To: lemonade@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B84793A67AF for ; Tue, 10 Jun 2008 19:12:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.527 X-Spam-Level: X-Spam-Status: No, score=-6.527 tagged_above=-999 required=5 tests=[AWL=0.072, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vGQptZ79Lyt4 for ; Tue, 10 Jun 2008 19:12:09 -0700 (PDT) Received: from dovecot.org (dovecot.org [82.118.211.50]) by core3.amsl.com (Postfix) with ESMTP id C2ED33A6768 for ; Tue, 10 Jun 2008 19:12:06 -0700 (PDT) Received: from [192.168.10.2] (xdsl-177-118.nblnetworks.fi [217.30.177.118]) by dovecot.org (Postfix) with ESMTP id 8221A16471E1 for ; Wed, 11 Jun 2008 05:11:55 +0300 (EEST) From: Timo Sirainen To: lemonade@ietf.org Date: Wed, 11 Jun 2008 05:11:54 +0300 Message-Id: <1213150314.3904.1086.camel@hurina> Mime-Version: 1.0 X-Mailer: Evolution 2.22.1 Subject: [lemonade] QRESYNC issue X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1686296134==" Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org --===============1686296134== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-YW3mymXXv2b/rCaLANR/" --=-YW3mymXXv2b/rCaLANR/ Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I think a future revision should say that unilaterally sent FETCH replies MUST contain UID field. Otherwise it's more or less impossible to figure out what messages they're referring to. Especially because of: > That is, servers SHOULD NOT send UIDs for previously expunged messages I really wish that had been a MUST NOT.. An example of valid input from a badly behaving server: * 0 EXISTS .. x noop =EF=BB=BF* 10 EXISTS =EF=BB=BF* VANISHED 1000:2000 * 3 FETCH (FLAGS (\Seen) MODSEQ (14749)) * 5 FETCH (FLAGS (\Seen) MODSEQ (14749)) =EF=BB=BF=EF=BB=BF* VANISHED 2000:3000 x OK NOOP Completed What is the client supposed to do with any of that information? All it can do is issue a FETCH command to find out if there are new messages in the mailbox - all the other information has to be discarded. If FETCH replies had UIDs the client could at least cache the flags and modseqs. --=-YW3mymXXv2b/rCaLANR/ Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQBITzRqyUhSUUBViskRAgtUAJ4x3g8zia2I1Nl4CT+iXXIZE9nPagCfXFXr JUu68kkl435HulMkP6pGvww= =TkfS -----END PGP SIGNATURE----- --=-YW3mymXXv2b/rCaLANR/-- --===============1686296134== 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://www.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade --===============1686296134==-- From lemonade-bounces@ietf.org Tue Jun 10 19:42:29 2008 Return-Path: X-Original-To: lemonade-archive@optimus.ietf.org Delivered-To: ietfarch-lemonade-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CE20F3A6905; Tue, 10 Jun 2008 19:42:29 -0700 (PDT) X-Original-To: lemonade@core3.amsl.com Delivered-To: lemonade@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C26FE3A6814 for ; Tue, 10 Jun 2008 19:42:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.23 X-Spam-Level: X-Spam-Status: No, score=-6.23 tagged_above=-999 required=5 tests=[AWL=-0.231, BAYES_00=-2.599, J_CHICKENPOX_56=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2WcTLCYOjZWZ for ; Tue, 10 Jun 2008 19:42:25 -0700 (PDT) Received: from dovecot.org (dovecot.org [82.118.211.50]) by core3.amsl.com (Postfix) with ESMTP id 724E43A6905 for ; Tue, 10 Jun 2008 19:42:25 -0700 (PDT) Received: from [192.168.10.2] (xdsl-177-118.nblnetworks.fi [217.30.177.118]) by dovecot.org (Postfix) with ESMTP id 9F05816471E1; Wed, 11 Jun 2008 05:42:18 +0300 (EEST) From: Timo Sirainen To: Alexey Melnikov In-Reply-To: <47DBFBCF.5060201@isode.com> References: <1205592725.11220.1064.camel@hurina> <47DBFBCF.5060201@isode.com> Date: Wed, 11 Jun 2008 05:42:18 +0300 Message-Id: <1213152138.3904.1095.camel@hurina> Mime-Version: 1.0 X-Mailer: Evolution 2.22.1 Cc: lemonade@ietf.org Subject: Re: [lemonade] QRESYNC CLOSE race condition X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1133603452==" Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org --===============1133603452== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-1J2gyfua2AdKgvUMDzDT" --=-1J2gyfua2AdKgvUMDzDT Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Sat, 2008-03-15 at 16:39 +0000, Alexey Melnikov wrote: > Timo Sirainen wrote: >=20 > >If CLOSE expunges messages it sends the new HIGHESTMODSEQ in the tagged > >reply. I guess the intent is that client could cache it and avoid > >resyncing the expunge later. But what if two clients do changes: > > > >C1: 1 store 1 +flags.silent \deleted > >S1: * 1 FETCH (modseq 1) > >S1: 1 OK > > > >C2: 2 store 2 +flags.silent \deleted > >S2: * 2 FETCH (modseq 2) > >S2: 2 OK > >C2: 3 expunge > >S2: * VANISHED 2 > >S2: 3 OK [HIGHESTMODSEQ 3] > >C2: 4 store 3 flags.silent \seen > >S2: * 3 FETCH (modseq 4) > >S2: 4 OK > > > >C1: 5 close > >S1: 5 OK [HIGHESTMODSEQ 5] > > > >Client 1 now missed that UID 2 was just expunged and 3 had its flag > >changed. To avoid this the server would have to send instead: > > > >C1: 5 close > >S1: * VANISHED 2 > >S1: * 3 FETCH (FLAGS (\Seen) modseq 4) > >S1: 5 OK [HIGHESTMODSEQ 5] > > > >Or did I miss something? > > =20 > > > Your proposal seems correct. QRESYNCbis should include your example. I'm beginning to think that CLOSE should always send VANISHED reply, because the client can't reliably figure out what was expunged. For example: C1: 2 STORE 1 +FLAGS.SILENT \Deleted S1: * 1 FETCH (MODSEQ 1) S1: 2 OK C2: 1 STORE 2 +FLAGS.SILENT \Deleted =EF=BB=BFS1: * 2 FETCH (MODSEQ 2) S2: 1 OK C1: 3 CLOSE S1: 3 [HIGHESTMODSEQ 3] The client probably thought that only message 1 was expunged, so it doesn't register the second expunge. And it probably never will if it uses QRESYNC to find out only about new expunges. And even worse example would be if the second client had also removed the \Deleted flag from message 1. Then the first client would have registered wrong message to be expunged. --=-1J2gyfua2AdKgvUMDzDT Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQBITzuKyUhSUUBViskRAu1oAJsHMrcAX3zj/Cl4Fg3HBuvaK215cgCglFja aeHfBc7eWNZXoelAc2P0OU8= =20Hv -----END PGP SIGNATURE----- --=-1J2gyfua2AdKgvUMDzDT-- --===============1133603452== 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://www.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade --===============1133603452==-- From lemonade-bounces@ietf.org Wed Jun 11 04:52:21 2008 Return-Path: X-Original-To: lemonade-archive@optimus.ietf.org Delivered-To: ietfarch-lemonade-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 16AE73A6838; Wed, 11 Jun 2008 04:52:21 -0700 (PDT) X-Original-To: lemonade@core3.amsl.com Delivered-To: lemonade@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E67B73A6AA1 for ; Wed, 11 Jun 2008 04:52:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.52 X-Spam-Level: X-Spam-Status: No, score=-6.52 tagged_above=-999 required=5 tests=[AWL=0.079, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lB8NdbJq4pu8 for ; Wed, 11 Jun 2008 04:52:18 -0700 (PDT) Received: from dovecot.org (dovecot.org [82.118.211.50]) by core3.amsl.com (Postfix) with ESMTP id 5EC933A67E6 for ; Wed, 11 Jun 2008 04:52:18 -0700 (PDT) Received: from [192.168.10.2] (xdsl-177-118.nblnetworks.fi [217.30.177.118]) by dovecot.org (Postfix) with ESMTP id 17ED7FA8A4E for ; Wed, 11 Jun 2008 14:52:09 +0300 (EEST) From: Timo Sirainen To: lemonade@ietf.org In-Reply-To: <1209773856.9518.31.camel@hurina> References: <1209773856.9518.31.camel@hurina> Date: Wed, 11 Jun 2008 14:52:05 +0300 Message-Id: <1213185125.3904.1116.camel@hurina> Mime-Version: 1.0 X-Mailer: Evolution 2.22.1 Subject: Re: [lemonade] Another QRESYNC race condition X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1907807702==" Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org --===============1907807702== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-VPfRHcYAZsU3NPJ19UKF" --=-VPfRHcYAZsU3NPJ19UKF Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Sat, 2008-05-03 at 03:17 +0300, Timo Sirainen wrote: > > After completing a full synchronization, the client MUST also take > > note of any unsolicited MODSEQ FETCH data items received from the > > server. Whenever the client receives a tagged response to a command= , > > it calculates the highest value among all MODSEQ FETCH data items > > received since the last tagged response. If this value is bigger > > than the client's copy of the HIGHESTMODSEQ value, then the client > > MUST use this value as its new HIGHESTMODSEQ value. >=20 > Problem: >=20 > C1: a store 1 +flags \seen > S1: * 1 FETCH (FLAGS (\Seen) MODSEQ (1)) > S1: a OK >=20 > C2: b expunge > S2: * VANISHED 1234 > S2: b OK [HIGHESTMODSEQ 2] >=20 > C1: c store 1 -flags \seen > =EF=BB=BFS1: * 1 FETCH (FLAGS () MODSEQ (3)) > S1: c OK >=20 > If C1 disconnects here, the next resync won't show that UID 1234 was > expunged, because it uses 3 as the last seen HIGHESTMODSEQ. What do you think about this solution: If server sends untagged FETCH replies with MODSEQ fields but there are pending EXPUNGE/VANISHED replies, the server sends HIGHESTMODSEQ which is below the EXPUNGEs' modseq. Example solving the above problem: C1: a store 1 +flags \seen S1: * 1 FETCH (FLAGS (\Seen) MODSEQ (1)) S1: a OK C2: b expunge S2: * VANISHED 1234 S2: b OK [HIGHESTMODSEQ 2] C1: c store 1 -flags \seen =EF=BB=BFS1: * 1 FETCH (FLAGS () MODSEQ (3)) S1: * OK [HIGHESTMODSEQ 1] S1: c OK Or it could be in the tagged reply as well, doesn't really matter (except it can't be used with STORE UNCHANGEDSINCE that fails with [MODIFIED]). (As an optimization the HIGHESTMODSEQ could also be sent after a non-EXPUNGE/CLOSE command sends a VANISHED reply.) Client logic would then be: =EF=BB=BF1. When receiving FETCH MODSEQs, keep track of the highest value b= ut don't update HIGHESTMODSEQ yet. 2. When untagged or tagged HIGHESTMODSEQ resp code is received, set highest FETCH MODSEQ value to zero. Always update the current HIGHESTMODSEQ value with the given value, even if it shrinks. 3. When receiving a tagged reply process its resp code =EF=BB=BFfirst. Afte= r that if highest FETCH MODSEQ value is larger than HIGHESTMODSEQ, update it. After this change and making the server always send UID in FETCH replies my QRESYNC stress tester (http://imapwiki.org/ImapTest) doesn't lose changes anymore. If you want to try yourself, this command works pretty well: ./imaptest checkpoint=3D1 logout=3D10 clients=3D2 random qresync delay=3D1 --=-VPfRHcYAZsU3NPJ19UKF Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQBIT7xlyUhSUUBViskRAtGnAJ40VU4vKW7Zg5tYlWB+submOVdxhACeJ6qD aVq2eTjNE3Vj1Ny5t0VCa+E= =jD/g -----END PGP SIGNATURE----- --=-VPfRHcYAZsU3NPJ19UKF-- --===============1907807702== 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://www.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade --===============1907807702==-- From lemonade-bounces@ietf.org Thu Jun 12 03:18:34 2008 Return-Path: X-Original-To: lemonade-archive@optimus.ietf.org Delivered-To: ietfarch-lemonade-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C41AE3A6A69; Thu, 12 Jun 2008 03:18:34 -0700 (PDT) X-Original-To: lemonade@core3.amsl.com Delivered-To: lemonade@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B3FD93A6A69 for ; Thu, 12 Jun 2008 03:18:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.003 X-Spam-Level: X-Spam-Status: No, score=-2.003 tagged_above=-999 required=5 tests=[AWL=-0.396, BAYES_00=-2.599, DATE_IN_PAST_12_24=0.992] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sglQU5o47gY1 for ; Thu, 12 Jun 2008 03:18:33 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id AFB173A6A2B for ; Thu, 12 Jun 2008 03:18:32 -0700 (PDT) Received: from [172.16.2.147] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Thu, 12 Jun 2008 11:18:59 +0100 Message-ID: <48504C18.6060800@isode.com> Date: Wed, 11 Jun 2008 23:05:12 +0100 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: Timo Sirainen References: <8B9B8F32-8DEF-40B9-992E-9337FB7AE344@standardstrack.com> <1210951366.9518.654.camel@hurina> <48312F7D.8090103@isode.com> <1211191304.9518.755.camel@hurina> <4835D000.4080808@isode.com> <1211745339.3904.166.camel@hurina> In-Reply-To: <1211745339.3904.166.camel@hurina> MIME-Version: 1.0 Cc: lemonade Subject: Re: [lemonade] WGLC NOTIFY X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org Timo Sirainen wrote: >On Thu, 2008-05-22 at 23:56 +0400, Alexey Melnikov wrote: > [...] >>>a notify set (selected (MessageNew MessageExpunge)) (personal >>>(SubscriptionChange)) >>> >>This would result in MessageNew and MessageExpunge events for the >>currently selected mailbox (whether it is a personal one or not) and >>subscription change notifications for all personal mailboxes except for >>the currently selected one (if it is a personal mailbox). >> >>Hmm, this raises an interesting question: is the "except for the >>currently selected" part in the last sentence is what we actually want? >>Should "Selected"only apply to message level events? >> >> >I think that would be better. > Based on private replies from Arnt and Peter, I will be changing the document to reflect that. If anybody objects, please speak up now. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Thu Jun 12 03:18:35 2008 Return-Path: X-Original-To: lemonade-archive@optimus.ietf.org Delivered-To: ietfarch-lemonade-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EA5103A6A4F; Thu, 12 Jun 2008 03:18:35 -0700 (PDT) X-Original-To: lemonade@core3.amsl.com Delivered-To: lemonade@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5FF233A6A69 for ; Thu, 12 Jun 2008 03:18:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.942 X-Spam-Level: X-Spam-Status: No, score=-1.942 tagged_above=-999 required=5 tests=[AWL=-0.412, BAYES_00=-2.599, DATE_IN_PAST_06_12=1.069] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IFpMGbM3bbcx for ; Thu, 12 Jun 2008 03:18:33 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id 4E7413A6A63 for ; Thu, 12 Jun 2008 03:18:33 -0700 (PDT) Received: from [172.16.2.147] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Thu, 12 Jun 2008 11:19:00 +0100 Message-ID: <4850501E.2080504@isode.com> Date: Wed, 11 Jun 2008 23:22:22 +0100 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: Timo Sirainen References: <8B9B8F32-8DEF-40B9-992E-9337FB7AE344@standardstrack.com> <1210951366.9518.654.camel@hurina> <48312F7D.8090103@isode.com> <1211191304.9518.755.camel@hurina> <4835D000.4080808@isode.com> <1211745339.3904.166.camel@hurina> <483BAB35.2080806@isode.com> <1B7D968F-7A77-40FC-AFD6-ADF3C2826822@iki.fi> <484657A5.5070202@isode.com> <1212595278.3904.735.camel@hurina> <1212675916.3904.858.camel@hurina> In-Reply-To: MIME-Version: 1.0 Cc: lemonade Subject: Re: [lemonade] WGLC NOTIFY X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org Timo Sirainen wrote: > On Jun 5, 2008, at 5:25 PM, Timo Sirainen wrote: > >> Currently there's no way to specify the default IMAP server behavior >> with NOTIFY: Send MessageNew and FlagChange as soon as they happen, but >> send MessageExpunge only when it's safe to do so. If MessageExpunge >> wasn't tied to MessageNew I'd be happier. > > If we assumed nothing was tied together, the current NOTIFY behavior > would be: > > - (MessageNew MessageExpunge FlagChange) : Everything sent immediately > - (MessageNew FlagChange) : EXISTS and flags sent immediately, > expunges delayed > - (MessageNew) : EXISTS sent immediately, expunges delayed, flag > changes not sent at all > - () : EXISTS and expunges delayed, flag changes not sent at all The idea behind NOTIFY NONE or NOTIFY SET (SELECTED NONE) is to disable any type of notifications whatsoever. This would allow the client to work on a snapshot of a mailbox and avoid receiving any extra traffic on a connection for which the client doesn't want to receive any notifications (This is analogous to signal blocking for a thread). > The closest default IMAP behavior would be (MessageNew FlagChange). > Most servers delay sending the changes until a command is started, > but that's not required by RFC 3501 so I don't think it matters. > > Perhaps MessageNew should be always enabled? This would disallow the NOTIFY NONE behavior. > EXISTS replies can't be disabled entirely in any case and I don't see > any benefit in delaying them (if client didn't want to see new events > immediately, it wouldn't have called NOTIFY in the first place). With > this done and decoupling MessageExpunge there would be no tied events > left anymore. That would nicely simplify the specification. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Thu Jun 12 03:18:36 2008 Return-Path: X-Original-To: lemonade-archive@optimus.ietf.org Delivered-To: ietfarch-lemonade-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0E3D028C0EF; Thu, 12 Jun 2008 03:18:36 -0700 (PDT) X-Original-To: lemonade@core3.amsl.com Delivered-To: lemonade@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C929628C0EF for ; Thu, 12 Jun 2008 03:18:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.919 X-Spam-Level: X-Spam-Status: No, score=-1.919 tagged_above=-999 required=5 tests=[AWL=-0.389, BAYES_00=-2.599, DATE_IN_PAST_06_12=1.069] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n-lt1JpFw81M for ; Thu, 12 Jun 2008 03:18:34 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id D724D3A6A2B for ; Thu, 12 Jun 2008 03:18:33 -0700 (PDT) Received: from [172.16.2.147] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Thu, 12 Jun 2008 11:19:01 +0100 Message-ID: <48505164.6080809@isode.com> Date: Wed, 11 Jun 2008 23:27:48 +0100 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: Lemonade WG MIME-Version: 1.0 Subject: [lemonade] Status of the IMAP NOTIFY document X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org I think we have the following open issues in IMAP NOTIFY (ignoring the ones that I've addressed while discussing Timo's comments): 1). Decoupling of MessageNew and MessageExpunge events. 2). What happens to message events in the currently selected mailbox if NOTIFY SET is used, but SELECTED isn't specified? I think Timo suggested to use the default behavior (i.e. before NOTIFY SET is specified). I tend to think that this might be a reasonable choice and would cover some of the use cases proposed by Timo. Comments? _______________________________________________ lemonade mailing list lemonade@ietf.org https://www.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Thu Jun 12 03:44:17 2008 Return-Path: X-Original-To: lemonade-archive@optimus.ietf.org Delivered-To: ietfarch-lemonade-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 67B593A697A; Thu, 12 Jun 2008 03:44:17 -0700 (PDT) X-Original-To: lemonade@core3.amsl.com Delivered-To: lemonade@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3E7213A697A for ; Thu, 12 Jun 2008 03:44:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.825 X-Spam-Level: X-Spam-Status: No, score=-5.825 tagged_above=-999 required=5 tests=[AWL=-0.622, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0O4TOG8K6ZMB for ; Thu, 12 Jun 2008 03:44:15 -0700 (PDT) Received: from dovecot.org (dovecot.org [82.118.211.50]) by core3.amsl.com (Postfix) with ESMTP id DB63F3A694A for ; Thu, 12 Jun 2008 03:44:14 -0700 (PDT) Received: from [192.168.10.2] (xdsl-177-118.nblnetworks.fi [217.30.177.118]) by dovecot.org (Postfix) with ESMTP id AC2A616471E1; Thu, 12 Jun 2008 13:44:08 +0300 (EEST) From: Timo Sirainen To: Alexey Melnikov In-Reply-To: <4850501E.2080504@isode.com> References: <8B9B8F32-8DEF-40B9-992E-9337FB7AE344@standardstrack.com> <1210951366.9518.654.camel@hurina> <48312F7D.8090103@isode.com> <1211191304.9518.755.camel@hurina> <4835D000.4080808@isode.com> <1211745339.3904.166.camel@hurina> <483BAB35.2080806@isode.com> <1B7D968F-7A77-40FC-AFD6-ADF3C2826822@iki.fi> <484657A5.5070202@isode.com> <1212595278.3904.735.camel@hurina> <1212675916.3904.858.camel@hurina> <4850501E.2080504@isode.com> Date: Thu, 12 Jun 2008 13:44:08 +0300 Message-Id: <1213267448.3904.1211.camel@hurina> Mime-Version: 1.0 X-Mailer: Evolution 2.22.1 Cc: lemonade Subject: Re: [lemonade] WGLC NOTIFY X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0187911444==" Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org --===============0187911444== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-q5V7ZT4xIRvJJR44wQ5B" --=-q5V7ZT4xIRvJJR44wQ5B Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wed, 2008-06-11 at 23:22 +0100, Alexey Melnikov wrote: > >> Currently there's no way to specify the default IMAP server behavior > >> with NOTIFY: Send MessageNew and FlagChange as soon as they happen, b= ut > >> send MessageExpunge only when it's safe to do so. If MessageExpunge > >> wasn't tied to MessageNew I'd be happier. > > > > If we assumed nothing was tied together, the current NOTIFY behavior =20 > > would be: > > > > - (MessageNew MessageExpunge FlagChange) : Everything sent immediately > > - (MessageNew FlagChange) : EXISTS and flags sent immediately, =20 > > expunges delayed > > - (MessageNew) : EXISTS sent immediately, expunges delayed, flag =20 > > changes not sent at all > > - () : EXISTS and expunges delayed, flag changes not sent at all >=20 > The idea behind NOTIFY NONE or NOTIFY SET (SELECTED NONE) is to disable=20 > any type of notifications whatsoever. This would allow the client to=20 > work on a snapshot of a mailbox and avoid receiving any extra traffic on=20 > a connection for which the client doesn't want to receive any=20 > notifications (This is analogous to signal blocking for a thread). I hadn't noticed NONE before. That makes this situation even more complex.. > > The closest default IMAP behavior would be (MessageNew FlagChange). =20 > > Most servers delay sending the changes until a command is started,=20 > > but that's not required by RFC 3501 so I don't think it matters. > > > > Perhaps MessageNew should be always enabled? >=20 > This would disallow the NOTIFY NONE behavior. What if there was first a big switch between "NONE" vs. "something" and then some finer switches under "something": =EF=BB=BFa) NONE - nothing sent at all. b) - MessageNew always sent immediately - MessageExpunge always sent, but could be either delayed or immediate - Flags, annotations, etc. are optionally sent, but if they are they're always immediate I guess the b) option could be done by specifying that unless NONE is used, MessageNew is always used regardless of whether it's explicitly specified or not. It probably would be cleaner if the entire syntax was changed a bit: NOTIFY SELECTED [(optionals) [(fetch attributes)]] NOTIFY SELECTED none - nothing sent NOTIFY SELECTED delayed - delayed expunges, immediate EXISTS, no flag changes NOTIFY SELECTED delayed (FlagChange) - delayed expunges, immediate EXISTS and flag changes NOTIFY SELECTED immediate (FlagChange) (UID FLAGS) - immediate expunges, EXISTS and flag changes, new messages return FETCH (UID FLAGS) =EF=BB=BFNOTIFY SELECTED immediate () (UID FLAGS) - no flags, immediate others --=-q5V7ZT4xIRvJJR44wQ5B Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQBIUP34yUhSUUBViskRAuzaAJ9wJB3CO8uk5z0MmoOtwNvEfIYKgACePSXx hb40+kAZZY5qtbAb0lL7nEk= =zQjR -----END PGP SIGNATURE----- --=-q5V7ZT4xIRvJJR44wQ5B-- --===============0187911444== 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://www.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade --===============0187911444==-- From lemonade-bounces@ietf.org Thu Jun 12 15:59:20 2008 Return-Path: X-Original-To: lemonade-archive@optimus.ietf.org Delivered-To: ietfarch-lemonade-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8F5453A6A30; Thu, 12 Jun 2008 15:59:20 -0700 (PDT) X-Original-To: lemonade@core3.amsl.com Delivered-To: lemonade@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C3BE73A6A30 for ; Thu, 12 Jun 2008 15:59:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7Gv9AQ-uUBI2 for ; Thu, 12 Jun 2008 15:59:19 -0700 (PDT) Received: from smtp102-mob.biz.mail.re2.yahoo.com (smtp102-mob.biz.mail.re2.yahoo.com [206.190.36.117]) by core3.amsl.com (Postfix) with SMTP id CE6B93A691E for ; Thu, 12 Jun 2008 15:59:18 -0700 (PDT) Received: (qmail 85517 invoked from network); 12 Jun 2008 22:59:45 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Received:X-YMail-OSG:X-Yahoo-Newman-Property:X-rim-org-msg-ref-id:Message-ID:Reply-To:X-Priority:Sensitivity:Importance:To:Subject:From:Date:Content-Type:MIME-Version; b=RJx/101BRTsoryUkmoA+x0OzYiJynBH5mvPQnqLYcCpazV8ReDvhe+zcyyzY6+yzg8yF66544crmTQpt+Xrcv+4NMypDDEJco7TYcSMiNNo3jJK/6DRaJQLlEQ9hykKt3Om/mIwyRLlJQA0+brgK+ZzBcoEUSVOX4Zc9khJGiFc= ; Received: from unknown (HELO bda380.bisx.prod.on.blackberry) (awe3bz@67.223.81.173 with xymcookie) by smtp102-mob.biz.mail.re2.yahoo.com with SMTP; 12 Jun 2008 22:59:44 -0000 X-YMail-OSG: Zd8pToMVM1mZntxB6Mx.Tn9BFBTJrmmfqI5cZRbcd.HOinqHVJPMruOrKQWHfiHH9bvC0P.FSihVC7.ji2QzR5z7zf6Ku0O_4tbb8pXUlstYYut3sWLlIupRHZ58T1Pidg-- X-Yahoo-Newman-Property: ymail-3 X-rim-org-msg-ref-id: 587706165 Message-ID: <587706165-1213311578-cardhu_decombobulator_blackberry.rim.net-537144736-@bxe014.bisx.prod.on.blackberry> X-Priority: Normal Sensitivity: Normal Importance: Normal To: lemonade@ietf.org From: ewburger@yahoo.com Date: Thu, 12 Jun 2008 22:59:21 +0000 MIME-Version: 1.0 Subject: [lemonade] IETF 72 Session X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: ewburger@yahoo.com List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org LEMONADE Session 1 (2.5 hours) Friday, Morning Session I 0900-1130 Room Name: Conservatory Sent from my Verizon Wireless BlackBerry _______________________________________________ lemonade mailing list lemonade@ietf.org https://www.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Fri Jun 13 14:46:43 2008 Return-Path: X-Original-To: lemonade-archive@optimus.ietf.org Delivered-To: ietfarch-lemonade-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BFE313A6833; Fri, 13 Jun 2008 14:46:42 -0700 (PDT) X-Original-To: lemonade@core3.amsl.com Delivered-To: lemonade@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BBEF23A689E for ; Fri, 13 Jun 2008 14:46:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.046 X-Spam-Level: X-Spam-Status: No, score=-3.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uyMkY1T2Kcn8 for ; Fri, 13 Jun 2008 14:46:38 -0700 (PDT) Received: from sca-es-mail-1.sun.com (sca-es-mail-1.Sun.COM [192.18.43.132]) by core3.amsl.com (Postfix) with ESMTP id DB5583A6833 for ; Fri, 13 Jun 2008 14:46:38 -0700 (PDT) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m5DLl98B008357 for ; Fri, 13 Jun 2008 14:47:10 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K2F00G018E7D000@fe-sfbay-09.sun.com> (original mail from Chris.Newman@Sun.COM) for lemonade@ietf.org; Fri, 13 Jun 2008 14:47:09 -0700 (PDT) Received: from [10.1.110.5] by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K2F00H8Y8I3QHD0@fe-sfbay-09.sun.com>; Fri, 13 Jun 2008 14:46:53 -0700 (PDT) Date: Fri, 13 Jun 2008 14:46:53 -0700 From: Chris Newman In-reply-to: To: Timo Sirainen , lemonade Message-id: <5E70A5B2C8706243D93689A5@446E7922C82D299DB29D899F> MIME-version: 1.0 X-Mailer: Mulberry/4.0.8 (Mac OS X) Content-disposition: inline References: <8B9B8F32-8DEF-40B9-992E-9337FB7AE344@standardstrack.com> <1210951366.9518.654.camel@hurina> <48312F7D.8090103@isode.com> <1211191304.9518.755.camel@hurina> <4835D000.4080808@isode.com> <1211745339.3904.166.camel@hurina> <483BAB35.2080806@isode.com> <1B7D968F-7A77-40FC-AFD6-ADF3C2826822@iki.fi> <484657A5.5070202@isode.com> <1212595278.3904.735.camel@hurina> <1212675916.3904.858.camel@hurina> Subject: Re: [lemonade] WGLC NOTIFY X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org Since my co-worker was not participating in this conversation, I'm going to jump in and explain the reason to link new & expunge events in NOTIFY. [I'm speaking as a technical participant, not as an area director. As AD I will support advancement of IMAP NOTIFY regardless of the resolution of this issue if the WG chair believes it has WG rough-consensus.] An IMAP server has to keep a mapping from sequence numbers to physical messages. The Cyrus IMAP implementation (at least the older versions I've worked with) does this via a file descriptor to a memory-mapped file with fixed-length records. That's a fairly elegant implementation because the scalability is limited by VM address space (rather than actual RAM) and the most current mapping is in the on-disk file, while older mappings are retained only as long as a process has the fd open and are automatically cleaned up by the filesystem when unused. Within that model, as soon as a MessageExpunge event actually occurs, the MessageNew events stop coming to MSN-only server processes until they issue a non-MSN sensitive command. So there is an inherent linkage between the two event types. In order to truly decouple the events with that server architecture, the server would have to create a new temporary pre-expunge-MSN to post-expunge-MSN mapping table between the time the expunge happened and the client issued a non-MSN sensitive command in order to continue generating MessageNew events. That's quite a bit of new server complexity (with scalability implications) for very limited benefit. Now I can't speak for the current Cyrus Server maintainers although I'd like to hear from them on this topic. But the IMAP server Sun sells largely retains this part of the design and the additional complexity of implementing the full de-coupling is likely to make us choose not to implement NOTIFY. I did think of a compromise to de-coupling the events. Introduce a new "ExpungePending" event. If you ask for MessageNew without MessageExpunge, then the server can send ExpungePending to the client and cease sending MessageNew events until the client triggers the EXPUNGE responses. I'm describing the compromise not because I think it's a good idea (linking the events is much simpler architecturally), but because it shows the edge of the server implementation issue. Any comments from other Cyrus-based implementers? - Chris --On June 6, 2008 5:49:11 +0300 Timo Sirainen wrote: > On Jun 5, 2008, at 5:25 PM, Timo Sirainen wrote: > >> Currently there's no way to specify the default IMAP server behavior >> with NOTIFY: Send MessageNew and FlagChange as soon as they happen, >> but >> send MessageExpunge only when it's safe to do so. If MessageExpunge >> wasn't tied to MessageNew I'd be happier. > > If we assumed nothing was tied together, the current NOTIFY behavior > would be: > > - (MessageNew MessageExpunge FlagChange) : Everything sent immediately > - (MessageNew FlagChange) : EXISTS and flags sent immediately, expunges > delayed > - (MessageNew) : EXISTS sent immediately, expunges delayed, flag > changes not sent at all > - () : EXISTS and expunges delayed, flag changes not sent at all > > The closest default IMAP behavior would be (MessageNew FlagChange). Most > servers delay sending the changes until a command is started, but that's > not required by RFC 3501 so I don't think it matters. > > Perhaps MessageNew should be always enabled? EXISTS replies can't be > disabled entirely in any case and I don't see any benefit in delaying > them (if client didn't want to see new events immediately, it wouldn't > have called NOTIFY in the first place). With this done and decoupling > MessageExpunge there would be no tied events left anymore. That would > nicely simplify the specification. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Fri Jun 13 18:45:25 2008 Return-Path: X-Original-To: lemonade-archive@optimus.ietf.org Delivered-To: ietfarch-lemonade-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 76C0B3A69F7; Fri, 13 Jun 2008 18:45:21 -0700 (PDT) X-Original-To: lemonade@ietf.org Delivered-To: lemonade@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 1540F3A6A15; Fri, 13 Jun 2008 18:45:02 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20080614014506.1540F3A6A15@core3.amsl.com> Date: Fri, 13 Jun 2008 18:45:02 -0700 (PDT) Cc: lemonade@ietf.org Subject: [lemonade] I-D Action:draft-ietf-lemonade-notifications-09.txt X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: lemonade-bounces@ietf.org 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 : Lemonade Notifications Architecture Author(s) : R. Gellens, S. Maes Filename : draft-ietf-lemonade-notifications-09.txt Pages : 17 Date : 2008-06-13 This document discusses how to provide notification and filtering mechanisms to mail stores to meet Lemonade goals. This document also discusses the use of server to server notifications, and how server to server notifications fit into an architecture which provides server to client notifications. Gellens [page 1] Expires December 2008 Internet Draft Lemonade Notifications Architecture June 2008 A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-lemonade-notifications-09.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ 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: Message/External-body; name="draft-ietf-lemonade-notifications-09.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-06-13184039.I-D@ietf.org> --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://www.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade --NextPart-- From lemonade-bounces@ietf.org Fri Jun 13 22:23:17 2008 Return-Path: X-Original-To: lemonade-archive@optimus.ietf.org Delivered-To: ietfarch-lemonade-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4C1383A694B; Fri, 13 Jun 2008 22:23:17 -0700 (PDT) X-Original-To: lemonade@core3.amsl.com Delivered-To: lemonade@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3B1B63A68BE for ; Fri, 13 Jun 2008 22:23:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.497 X-Spam-Level: X-Spam-Status: No, score=-6.497 tagged_above=-999 required=5 tests=[AWL=0.102, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gQTD3rvnTHyK for ; Fri, 13 Jun 2008 22:23:15 -0700 (PDT) Received: from dovecot.org (dovecot.org [82.118.211.50]) by core3.amsl.com (Postfix) with ESMTP id CCE123A694B for ; Fri, 13 Jun 2008 22:23:14 -0700 (PDT) Received: from [192.168.10.200] (xdsl-177-118.nblnetworks.fi [217.30.177.118]) by dovecot.org (Postfix) with ESMTP id A3E1816471E8; Sat, 14 Jun 2008 08:23:16 +0300 (EEST) Message-Id: <27BE9A2F-420C-4532-8902-AC28460A2CBE@iki.fi> From: Timo Sirainen To: Chris Newman In-Reply-To: <5E70A5B2C8706243D93689A5@446E7922C82D299DB29D899F> Mime-Version: 1.0 (Apple Message framework v924) Date: Sat, 14 Jun 2008 08:23:11 +0300 References: <8B9B8F32-8DEF-40B9-992E-9337FB7AE344@standardstrack.com> <1210951366.9518.654.camel@hurina> <48312F7D.8090103@isode.com> <1211191304.9518.755.camel@hurina> <4835D000.4080808@isode.com> <1211745339.3904.166.camel@hurina> <483BAB35.2080806@isode.com> <1B7D968F-7A77-40FC-AFD6-ADF3C2826822@iki.fi> <484657A5.5070202@isode.com> <1212595278.3904.735.camel@hurina> <1212675916.3904.858.camel@hurina> <5E70A5B2C8706243D93689A5@446E7922C82D299DB29D899F> X-Pgp-Agent: GPGMail d51 (Leopard) X-Mailer: Apple Mail (2.924) Cc: lemonade Subject: Re: [lemonade] WGLC NOTIFY X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1832349481==" Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============1832349481== Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-37-1038073873" Content-Transfer-Encoding: 7bit This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-37-1038073873 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit On Jun 14, 2008, at 12:46 AM, Chris Newman wrote: > I did think of a compromise to de-coupling the events. Introduce a > new "ExpungePending" event. If you ask for MessageNew without > MessageExpunge, then the server can send ExpungePending to the > client and cease sending MessageNew events until the client triggers > the EXPUNGE responses. I'm describing the compromise not because I > think it's a good idea (linking the events is much simpler > architecturally), but because it shows the edge of the server > implementation issue. All I actually care about is that NOTIFY can be fully used by clients that want to use MSNs. Such clients would still want to see expunges, so I think they'd basically be sending IDLE whenever they're done sending commands. So I wouldn't mind if NOTIFY had a big switch that worked like: a) Immediate: Send expunges, exists and everything else immediately to client b) Delayed: Server is allowed (but not required) to delay all events until a command is executed that allows returning expunges (usually IDLE, but also others). --Apple-Mail-37-1038073873 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig content-transfer-encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) iEYEARECAAYFAkhTVb8ACgkQyUhSUUBVismLvQCgnFvz44kRzmsY8PZj5XFLH+tQ /GwAoKaR6i3aiQkc8oXZdDPFrWgJA19g =57GO -----END PGP SIGNATURE----- --Apple-Mail-37-1038073873-- --===============1832349481== 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://www.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade --===============1832349481==-- From lemonade-bounces@ietf.org Sun Jun 15 09:53:47 2008 Return-Path: X-Original-To: lemonade-archive@optimus.ietf.org Delivered-To: ietfarch-lemonade-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 264AC3A68D2; Sun, 15 Jun 2008 09:53:47 -0700 (PDT) X-Original-To: lemonade@core3.amsl.com Delivered-To: lemonade@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0C1653A68D2 for ; Sun, 15 Jun 2008 09:53:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.839 X-Spam-Level: X-Spam-Status: No, score=-1.839 tagged_above=-999 required=5 tests=[AWL=-0.459, BAYES_00=-2.599, DATE_IN_PAST_24_48=1.219] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hk5P7vv9mGiR for ; Sun, 15 Jun 2008 09:53:44 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id AB3BD3A6818 for ; Sun, 15 Jun 2008 09:53:43 -0700 (PDT) Received: from [192.168.0.2] ((unknown) [62.3.217.253]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Sun, 15 Jun 2008 17:54:21 +0100 X-SMTP-Protocol-Errors: NORDNS Message-ID: <4853E49D.3000304@isode.com> Date: Sat, 14 Jun 2008 16:32:45 +0100 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: Randall Gellens References: <48206629.5020305@isode.com> In-Reply-To: MIME-Version: 1.0 Cc: lemonade@ietf.org Subject: Re: [lemonade] WGLC Notifications X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org Randall Gellens wrote: > Woops! Sprry for not sending this earlier. Hi Randy, > At 3:07 PM +0100 5/6/08, Alexey Melnikov wrote: > >> Eric Burger wrote: >> >>> Work Group Last Call for Lemonade Notifications Architecture, >>> http://tools.ietf.org/html/draft-ietf-lemonade-notifications-08 >>> starts now and ends 5 May 2008. >> >> The draft is in much better shape now. >> >> Some comments below: >> >>> * NF and DF: When internal to the mail store, these are >>> >>> typically implemented using Sieve and hence a Sieve management >> >> > protocol is used for client modifications. See [IMAP-SIEVE] and >> > [MANAGE-SIEVE] for more information. When the NF is within a >> >>> notification server, it is out of scope of Lemonade. >> >> I don't think [IMAP-SIEVE] is relevant in case of NF or DF. >> Unless NF is invoked on message flag changes, etc. > > I'm happy deleting the reference to IMAP-SIEVE, however, if a client > is only interested in some mailboxes, rather than having a main Sieve > script send notifications for all new mail, it might be better to have > a per-mailbox Sieve script send notifications. Per mailbox scripts are not invoked on message delivery, so IMAP-Sieve is not going to help. IMAP-Sieve will only matter for IMAP APPEND, but I think this is a less common case than message delivery using SMTP/LMTP. Also APPENDs are likely to be caused by the user herself, so there would be no much point in notifying about them. > How about changing > See [IMAP-SIEVE] and [MANAGE-SIEVE] for more information. > > to > See [MANAGE-SIEVE] for more information. Per-mailbox > notifications might be implemented using a per-mailbox Sieve > script, for example, [IMAP-SIEVE]. > >> > Note that when implementing DF using Sieve, the 'enotify' >> >>> [SIEVE-NOTIFY] and 'variables' [SIEVE-VARIABLES] Sieve extensions >>> are needed. >> >> If NF is generating notifications on mail delivery, than 'enotify' + >> 'variables' is also needed there. >> If NF is generating notifications both on mail delivery and IMAP >> events, >> then 'enotify' + 'variables' are *only* needed in NF. > > I think I should change this to: > > Note that when implementing DF or NF using Sieve, the 'enotify' > [SIEVE-NOTIFY] and likely the 'variables' [SIEVE-VARIABLES] > Sieve extensions might be needed. > > And move it to be above the line that starts "The filters are > manageable" (since logically this belongs with the earlier text block). Ok. >> > 4. Push Email >> >>> A good user experience of "push email" requires that when >>> "interesting" events occur in the mail store, the client is >>> informed >>> so that it can connect and resynchronize. The Lemonade Profile >>> [LEMONADE-PROFILE] contains more information, especially in >>> Section >>> 4.1.2. >> >> I can't find section 4.1.2 in draft-ietf-lemonade-profile-bis-08.txt. > > I suppose the text moved in a prior revision. I think this should be > changed to "External Notifications". This is reasonable. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Mon Jun 16 22:58:01 2008 Return-Path: X-Original-To: lemonade-archive@optimus.ietf.org Delivered-To: ietfarch-lemonade-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 769A43A692D; Mon, 16 Jun 2008 22:58:01 -0700 (PDT) X-Original-To: lemonade@core3.amsl.com Delivered-To: lemonade@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F22D43A68EB for ; Mon, 16 Jun 2008 22:57:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.505 X-Spam-Level: X-Spam-Status: No, score=-6.505 tagged_above=-999 required=5 tests=[AWL=0.094, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6dj79cYMrxI7 for ; Mon, 16 Jun 2008 22:57:58 -0700 (PDT) Received: from dovecot.org (dovecot.org [82.118.211.50]) by core3.amsl.com (Postfix) with ESMTP id D3C6A3A6814 for ; Mon, 16 Jun 2008 22:57:57 -0700 (PDT) Received: from [192.168.10.2] (xdsl-177-118.nblnetworks.fi [217.30.177.118]) by dovecot.org (Postfix) with ESMTP id 8149416471E4 for ; Tue, 17 Jun 2008 08:58:05 +0300 (EEST) From: Timo Sirainen To: lemonade@ietf.org Date: Tue, 17 Jun 2008 08:58:05 +0300 Message-Id: <1213682285.3904.1402.camel@hurina> Mime-Version: 1.0 X-Mailer: Evolution 2.22.1 Subject: [lemonade] QRESYNC message sequence match data X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0685132785==" Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org --===============0685132785== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-LqgwjtE/6PpWPtji8SQP" --=-LqgwjtE/6PpWPtji8SQP Content-Type: text/plain Content-Transfer-Encoding: quoted-printable QRESYNC RFC explains only how to use the sequence match data to drop expunges from the beginning of the mailbox, but it's also possible to use them to drop expunges from the middle. For example: 1 select inbox (qresync (12345 1234 1:5 (1,3,5 1,5,10))) If only message 1 has been expunged, the server has to return 1: in VANISHED, but since it can find out that the current seq 2 (3-1) maps to uid 5 and the current seq 4 (5-1) maps to uid 10 there's no need to return anything else as expunged. Has anyone yet figured out the exact algorithm for this? I tried it a couple of months ago but since it didn't work after a couple of tries I got annoyed and implemented only the simple version. If no-one's done it yet I could try again and write some pseudo code. --=-LqgwjtE/6PpWPtji8SQP Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD4DBQBIV1JtyUhSUUBViskRAh0VAJwMjKYPuInakG6NglJm146xZ63MMQCWPj/Z TTEpWGIfV8g9yrpeJUCMGw== =YPZX -----END PGP SIGNATURE----- --=-LqgwjtE/6PpWPtji8SQP-- --===============0685132785== 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://www.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade --===============0685132785==-- From lemonade-bounces@ietf.org Tue Jun 17 20:04:29 2008 Return-Path: X-Original-To: lemonade-archive@optimus.ietf.org Delivered-To: ietfarch-lemonade-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3A08F3A6911; Tue, 17 Jun 2008 20:04:29 -0700 (PDT) X-Original-To: lemonade@core3.amsl.com Delivered-To: lemonade@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 938CA3A6912 for ; Tue, 17 Jun 2008 20:04:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.123 X-Spam-Level: X-Spam-Status: No, score=-1.123 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, HELO_MISMATCH_NET=0.611, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 03YBHpTGSv5p for ; Tue, 17 Jun 2008 20:04:26 -0700 (PDT) Received: from turner.dave.cridland.net (dsl-217-155-137-60.zen.co.uk [217.155.137.60]) by core3.amsl.com (Postfix) with ESMTP id 749FB3A6911 for ; Tue, 17 Jun 2008 20:04:25 -0700 (PDT) Received: from invsysm1 (shiny.isode.com [62.3.217.250]) by turner.dave.cridland.net (submission) via TCP with ESMTPA id ; Tue, 17 Jun 2008 10:09:51 +0100 References: <1213682285.3904.1402.camel@hurina> In-Reply-To: <1213682285.3904.1402.camel@hurina> MIME-Version: 1.0 Message-Id: <6416.1213693794.055513@invsysm1> Date: Tue, 17 Jun 2008 10:09:54 +0100 From: Dave Cridland To: Enhancements to Internet email to support diverse service enivronments X-Encoded: Changed encoding from 8Bit for 7bit transmission Cc: Timo Sirainen Subject: Re: [lemonade] QRESYNC message sequence match data X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org On Tue Jun 17 06:58:05 2008, Timo Sirainen wrote: > 1 select inbox (qresync (12345 1234 1:5 (1,3,5 1,5,10))) > = > If only message 1 has been expunged, the server has to return = > 1: of current seq 1> in VANISHED, but since it can find out that the > current seq 2 (3-1) maps to uid 5 and the current seq 4 (5-1) maps = > to > uid 10 there's no need to return anything else as expunged. The reason this works is because at the first point of mismatch, with = MSN S and UID U, (U-1) =3D> (S-1), and U doesn't exist. This indicates = that the client doesn't know that U has been expunged, but also that = it did know about all prior expunges - in other words, at (S-1), E is = 0, and at S, E is 1. (Note that I'm introducing the convenience of = S=3D0 =3D> U=3D0, and being rather blais=E9 with my maths and saying U-1 wh= en = I really mean the previous existing UID). At the second mismatch, U does exist, and U =3D> (S-1) - again, this = indicates that E is 1, and therefore there are no unwitnessed = expunges between the first and second mismatches. Knowing *which* single expunge is missed is only possible if there is = only one possibility - in this example, this will always be the case, = since the MSN sequence given by the client in its mapping has gaps of = only 1. Typically, however, you'd merely be able to usefully handle the cases = E=3D=3D0, E!=3D0 at each point in the sequence, and (a refinement which = isn't mentioned in the draft), dE =3D=3D 0 / dE !=3D 0 (ie, the expunges = missed between two points on the mapping). I'd missed the possibility of using the dE figures, that's quite = interesting. Dave. -- = Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@dave.cridland.net - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade _______________________________________________ lemonade mailing list lemonade@ietf.org https://www.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Fri Jun 20 05:30:03 2008 Return-Path: X-Original-To: lemonade-archive@optimus.ietf.org Delivered-To: ietfarch-lemonade-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 124F628C138; Fri, 20 Jun 2008 05:30:03 -0700 (PDT) X-Original-To: lemonade@ietf.org Delivered-To: lemonade@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id C2BDE3A6A74; Fri, 20 Jun 2008 05:30:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20080620123001.C2BDE3A6A74@core3.amsl.com> Date: Fri, 20 Jun 2008 05:30:01 -0700 (PDT) Cc: lemonade@ietf.org Subject: [lemonade] I-D Action:draft-ietf-lemonade-profile-bis-09.txt X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: lemonade-bounces@ietf.org 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 : The Lemonade Profile Author(s) : D. Cridland, et al. Filename : draft-ietf-lemonade-profile-bis-09.txt Pages : 35 Date : 2008-06-20 This document describes a profile (a set of required extensions, restrictions and usage modes) of the IMAP and mail submission protocols. This profile allows clients (especially those that are constrained in memory, bandwidth, processing power, or other areas) to efficiently use IMAP and Submission to access and submit mail. This includes the ability to forward received mail without needing to download and upload the mail, to optimize submission and to efficiently resynchronize in case of loss of connectivity with the server. The Lemonade profile relies upon several extensions to IMAP and Mail Submission protocols. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-lemonade-profile-bis-09.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ 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: Message/External-body; name="draft-ietf-lemonade-profile-bis-09.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-06-20051905.I-D@ietf.org> --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://www.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade --NextPart-- From lemonade-bounces@ietf.org Sat Jun 21 06:49:38 2008 Return-Path: X-Original-To: lemonade-archive@optimus.ietf.org Delivered-To: ietfarch-lemonade-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 03EE93A6928; Sat, 21 Jun 2008 06:49:38 -0700 (PDT) X-Original-To: lemonade@core3.amsl.com Delivered-To: lemonade@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1426E3A694D for ; Sat, 21 Jun 2008 06:49:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.67 X-Spam-Level: X-Spam-Status: No, score=-5.67 tagged_above=-999 required=5 tests=[AWL=0.929, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Sn+LH2ZPvUey for ; Sat, 21 Jun 2008 06:49:36 -0700 (PDT) Received: from dovecot.org (dovecot.org [82.118.211.50]) by core3.amsl.com (Postfix) with ESMTP id 42EFD3A6850 for ; Sat, 21 Jun 2008 06:49:35 -0700 (PDT) Received: from [192.168.10.2] (xdsl-177-118.nblnetworks.fi [217.30.177.118]) by dovecot.org (Postfix) with ESMTP id BBA301647223 for ; Sat, 21 Jun 2008 16:49:04 +0300 (EEST) From: Timo Sirainen To: lemonade In-Reply-To: <20080620123001.C2BDE3A6A74@core3.amsl.com> References: <20080620123001.C2BDE3A6A74@core3.amsl.com> Date: Sat, 21 Jun 2008 16:49:04 +0300 Message-Id: <1214056144.3904.1693.camel@hurina> Mime-Version: 1.0 X-Mailer: Evolution 2.22.1 Subject: Re: [lemonade] I-D Action:draft-ietf-lemonade-profile-bis-09.txt X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2072225620==" Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org --===============2072225620== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-F5I7+S9DK/MrBzYUdmkQ" --=-F5I7+S9DK/MrBzYUdmkQ Content-Type: text/plain Content-Transfer-Encoding: quoted-printable > In addition to this list, any Lemonade Message Stores MUST send the > CAPABILITY response code (see Section 7.1 of [IMAP]) in the initial > server greeting and after the LOGIN/AUTHENTICATE commands. Since some older clients want to issue CAPABILITY command always and just ignore the capabilities sent in greeting/LOGIN/AUTHENTICATE replies, how about a small change to this: "If a client issues a CAPABILITY command depite having already received the capability in the greeting, the server MAY omit the CAPABILITY response from the LOGIN/AUTHENTICATE commands." Or something like that. --=-F5I7+S9DK/MrBzYUdmkQ Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQBIXQbQyUhSUUBViskRAn0UAJ0WvuOI72S1q+4M+jK7Gkepxwq1rwCZAWzQ LTYwEy2wubVqASu9WYggXT8= =51cb -----END PGP SIGNATURE----- --=-F5I7+S9DK/MrBzYUdmkQ-- --===============2072225620== 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://www.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade --===============2072225620==-- From lemonade-bounces@ietf.org Sat Jun 21 07:22:15 2008 Return-Path: X-Original-To: lemonade-archive@optimus.ietf.org Delivered-To: ietfarch-lemonade-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 28E663A6850; Sat, 21 Jun 2008 07:22:15 -0700 (PDT) X-Original-To: lemonade@core3.amsl.com Delivered-To: lemonade@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 674073A6850 for ; Sat, 21 Jun 2008 07:22:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wNUNwZ124Uox for ; Sat, 21 Jun 2008 07:22:13 -0700 (PDT) Received: from blu0-omc4-s21.blu0.hotmail.com (blu0-omc4-s21.blu0.hotmail.com [65.55.111.160]) by core3.amsl.com (Postfix) with ESMTP id 2E9FE3A67F6 for ; Sat, 21 Jun 2008 07:22:13 -0700 (PDT) Received: from BLU126-W47 ([65.55.111.136]) by blu0-omc4-s21.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Sat, 21 Jun 2008 07:22:12 -0700 Message-ID: X-Originating-IP: [206.124.149.117] From: Mark Crispin To: Timo Sirainen , lemonade Date: Sat, 21 Jun 2008 07:22:12 -0700 Importance: Normal In-Reply-To: <1214056144.3904.1693.camel@hurina> References: <20080620123001.C2BDE3A6A74@core3.amsl.com> <1214056144.3904.1693.camel@hurina> MIME-Version: 1.0 X-OriginalArrivalTime: 21 Jun 2008 14:22:12.0388 (UTC) FILETIME=[326BB640:01C8D3AA] Subject: Re: [lemonade] I-D Action:draft-ietf-lemonade-profile-bis-09.txt X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: quoted-printable Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org > "If a client issues a CAPABILITY command depite having already received > the capability in the greeting, the server MAY omit the CAPABILITY > response from the LOGIN/AUTHENTICATE commands." This is a very bad idea. It makes assumptions about the client which are n= ot necessarily the case. _________________________________________________________________ The other season of giving begins 6/24/08. Check out the i=92m Talkathon. http://www.imtalkathon.com?source=3DTXT_EML_WLH_SeasonOfGiving _______________________________________________ lemonade mailing list lemonade@ietf.org https://www.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Sat Jun 21 07:23:50 2008 Return-Path: X-Original-To: lemonade-archive@optimus.ietf.org Delivered-To: ietfarch-lemonade-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CD9F228C0EA; Sat, 21 Jun 2008 07:23:50 -0700 (PDT) X-Original-To: lemonade@core3.amsl.com Delivered-To: lemonade@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3706F28C0EA for ; Sat, 21 Jun 2008 07:23:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.134 X-Spam-Level: X-Spam-Status: No, score=-6.134 tagged_above=-999 required=5 tests=[AWL=0.465, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f+3dAZBBHNmP for ; Sat, 21 Jun 2008 07:23:48 -0700 (PDT) Received: from dovecot.org (dovecot.org [82.118.211.50]) by core3.amsl.com (Postfix) with ESMTP id D62D928C0DD for ; Sat, 21 Jun 2008 07:23:47 -0700 (PDT) Received: from [192.168.10.2] (xdsl-177-118.nblnetworks.fi [217.30.177.118]) by dovecot.org (Postfix) with ESMTP id E40E316471FA for ; Sat, 21 Jun 2008 17:23:20 +0300 (EEST) From: Timo Sirainen To: lemonade In-Reply-To: <1214056144.3904.1693.camel@hurina> References: <20080620123001.C2BDE3A6A74@core3.amsl.com> <1214056144.3904.1693.camel@hurina> Date: Sat, 21 Jun 2008 17:23:20 +0300 Message-Id: <1214058200.3904.1699.camel@hurina> Mime-Version: 1.0 X-Mailer: Evolution 2.22.1 Subject: Re: [lemonade] I-D Action:draft-ietf-lemonade-profile-bis-09.txt X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0780599033==" Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org --===============0780599033== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-jN9AaLXYCqO+1f/d0FX8" --=-jN9AaLXYCqO+1f/d0FX8 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Also in sections 8.4.1 and 8.4.2: > Mail submission server opens IMAP connection to the IMAP server: >=20 > I: * OK [CAPABILITY IMAP4REV1 STARTTLS NAMESPACE LITERAL+ > CATENATE URLAUTH UIDPLUS CONDSTORE IDLE] imap.example.com > IMAP server ready .. > Note that if the IMAP server doesn't send CAPABILITY response code in > the greeting, the mail submission server must issue the CAPABILITY > command to learn about supported IMAP extensions as described in > [IMAP]. Perhaps it should rather say "if IMAP server doesn't send CAPABILITY response code in LOGIN/AUTHENTICATE command", since that's where servers seem to send the URLAUTH capability. --=-jN9AaLXYCqO+1f/d0FX8 Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQBIXQ7YyUhSUUBViskRAk6UAJ9nXpVtiiGbcecrkXVLnEW+yzV8lQCfd/NG 96khTFslarNvAupg5iyqFXA= =1eM/ -----END PGP SIGNATURE----- --=-jN9AaLXYCqO+1f/d0FX8-- --===============0780599033== 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://www.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade --===============0780599033==-- From lemonade-bounces@ietf.org Sat Jun 21 07:26:15 2008 Return-Path: X-Original-To: lemonade-archive@optimus.ietf.org Delivered-To: ietfarch-lemonade-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 217353A6950; Sat, 21 Jun 2008 07:26:15 -0700 (PDT) X-Original-To: lemonade@core3.amsl.com Delivered-To: lemonade@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 88ED43A67F6 for ; Sat, 21 Jun 2008 07:26:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.289 X-Spam-Level: X-Spam-Status: No, score=-6.289 tagged_above=-999 required=5 tests=[AWL=0.310, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cHWW4O8sgNYN for ; Sat, 21 Jun 2008 07:26:13 -0700 (PDT) Received: from dovecot.org (dovecot.org [82.118.211.50]) by core3.amsl.com (Postfix) with ESMTP id 7AD9228C0E5 for ; Sat, 21 Jun 2008 07:26:13 -0700 (PDT) Received: from [192.168.10.2] (xdsl-177-118.nblnetworks.fi [217.30.177.118]) by dovecot.org (Postfix) with ESMTP id B17D016471FA; Sat, 21 Jun 2008 17:25:46 +0300 (EEST) From: Timo Sirainen To: Mark Crispin In-Reply-To: References: <20080620123001.C2BDE3A6A74@core3.amsl.com> <1214056144.3904.1693.camel@hurina> Date: Sat, 21 Jun 2008 17:25:46 +0300 Message-Id: <1214058346.3904.1702.camel@hurina> Mime-Version: 1.0 X-Mailer: Evolution 2.22.1 Cc: lemonade Subject: Re: [lemonade] I-D Action:draft-ietf-lemonade-profile-bis-09.txt X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0035442646==" Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org --===============0035442646== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-kCnrrgEe/sHgV8upyn4S" --=-kCnrrgEe/sHgV8upyn4S Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Sat, 2008-06-21 at 07:22 -0700, Mark Crispin wrote: > > "If a client issues a CAPABILITY command depite having already received > > the capability in the greeting, the server MAY omit the CAPABILITY > > response from the LOGIN/AUTHENTICATE commands." >=20 > This is a very bad idea. It makes assumptions about the client which are= not necessarily the case. Even if the client didn't ignore them, what's the point of sending the same CAPABILITY reply to the client twice? (Assuming of course it doesn't change. If it does change, then sure it should be sent.) --=-kCnrrgEe/sHgV8upyn4S Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQBIXQ9qyUhSUUBViskRAmtXAJ9wBMDbJ2KF8xP8nQuIDSRbgCaJzQCgkou3 eTy5vdeA9hMPV1f/ubMWQmQ= =N8Ym -----END PGP SIGNATURE----- --=-kCnrrgEe/sHgV8upyn4S-- --===============0035442646== 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://www.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade --===============0035442646==-- From lemonade-bounces@ietf.org Sat Jun 21 07:46:11 2008 Return-Path: X-Original-To: lemonade-archive@optimus.ietf.org Delivered-To: ietfarch-lemonade-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EC0EA3A6982; Sat, 21 Jun 2008 07:46:11 -0700 (PDT) X-Original-To: lemonade@core3.amsl.com Delivered-To: lemonade@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C445B3A6980 for ; Sat, 21 Jun 2008 07:46:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3LBJO8h1+hlB for ; Sat, 21 Jun 2008 07:46:09 -0700 (PDT) Received: from kalyani.oryx.com (kalyani.oryx.com [195.30.37.30]) by core3.amsl.com (Postfix) with ESMTP id 541AC3A6981 for ; Sat, 21 Jun 2008 07:46:08 -0700 (PDT) Received: from kalyani.oryx.com (localhost.oryx.com [127.0.0.1]) by kalyani.oryx.com (Postfix) with ESMTP id EBE4D4AC64 for ; Sat, 21 Jun 2008 16:46:14 +0200 (CEST) Received: from 195.30.37.40 (HELO lochnagar.oryx.com) by kalyani.oryx.com with esmtp id 1214059574-5025-2226; Sat, 21 Jun 2008 16:46:14 +0200 Message-Id: Date: Sat, 21 Jun 2008 16:44:29 +0200 From: Arnt Gulbrandsen To: lemonade@ietf.org References: <20080620123001.C2BDE3A6A74@core3.amsl.com> <1214056144.3904.1693.camel@hurina> In-Reply-To: <1214056144.3904.1693.camel@hurina> Mime-Version: 1.0 Subject: Re: [lemonade] I-D Action:draft-ietf-lemonade-profile-bis-09.txt X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org Timo Sirainen writes: > Since some older clients want to issue CAPABILITY command always and > just ignore the capabilities sent in greeting/LOGIN/AUTHENTICATE > replies, [,,,] Pretty much all older clients need some sort of change to take advantage of the lemonade goodies. A bigger change than learning to parse the CAPABILITY response-code. Arnt _______________________________________________ lemonade mailing list lemonade@ietf.org https://www.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Sat Jun 21 07:55:50 2008 Return-Path: X-Original-To: lemonade-archive@optimus.ietf.org Delivered-To: ietfarch-lemonade-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 156A33A67F6; Sat, 21 Jun 2008 07:55:50 -0700 (PDT) X-Original-To: lemonade@core3.amsl.com Delivered-To: lemonade@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DB73C3A67F6 for ; Sat, 21 Jun 2008 07:55:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P8tKvrbMM7dX for ; Sat, 21 Jun 2008 07:55:48 -0700 (PDT) Received: from blu0-omc4-s21.blu0.hotmail.com (blu0-omc4-s21.blu0.hotmail.com [65.55.111.160]) by core3.amsl.com (Postfix) with ESMTP id 01F9C3A67B1 for ; Sat, 21 Jun 2008 07:55:47 -0700 (PDT) Received: from BLU126-W50 ([65.55.111.135]) by blu0-omc4-s21.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Sat, 21 Jun 2008 07:55:47 -0700 Message-ID: X-Originating-IP: [206.124.149.117] From: Mark Crispin To: Timo Sirainen Date: Sat, 21 Jun 2008 07:55:47 -0700 Importance: Normal In-Reply-To: <1214058346.3904.1702.camel@hurina> References: <20080620123001.C2BDE3A6A74@core3.amsl.com> <1214056144.3904.1693.camel@hurina> <1214058346.3904.1702.camel@hurina> MIME-Version: 1.0 X-OriginalArrivalTime: 21 Jun 2008 14:55:47.0326 (UTC) FILETIME=[E36AD9E0:01C8D3AE] Cc: lemonade Subject: Re: [lemonade] I-D Action:draft-ietf-lemonade-profile-bis-09.txt X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: quoted-printable Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org >>> "If a client issues a CAPABILITY command depite having already received >>> the capability in the greeting, the server MAY omit the CAPABILITY >>> response from the LOGIN/AUTHENTICATE commands." >> This is a very bad idea. It makes assumptions about the client which are= not necessarily the case. > Even if the client didn't ignore them, what's the point of sending the > same CAPABILITY reply to the client twice? (Assuming of course it > doesn't change. If it does change, then sure it should be sent.) Are you, personally, willing to guarantee that this proposed additional (an= d IMHO pointless) complexity will never cause a problem, now and in the fut= ure? It IS additional complexity. It is an added behavior rule, with implicatio= ns for both server and client. The sole apparent purpose is to save a few = octets of network traffic. The cost is that misbehavior by either client o= r server will cause bugs. I don't know why I'm bothering. Nobody pays me to work on IMAP any more (i= n fact, nobody is paying me at all). I should just shut up and go away. B= ut this proposal was just so bad and so unnecessary that I felt that I had = to say something. _________________________________________________________________ The other season of giving begins 6/24/08. Check out the i=92m Talkathon. http://www.imtalkathon.com?source=3DTXT_EML_WLH_SeasonOfGiving _______________________________________________ lemonade mailing list lemonade@ietf.org https://www.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Sat Jun 21 07:56:49 2008 Return-Path: X-Original-To: lemonade-archive@optimus.ietf.org Delivered-To: ietfarch-lemonade-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 430723A67F6; Sat, 21 Jun 2008 07:56:49 -0700 (PDT) X-Original-To: lemonade@core3.amsl.com Delivered-To: lemonade@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 258E03A67F6 for ; Sat, 21 Jun 2008 07:56:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.605 X-Spam-Level: X-Spam-Status: No, score=-3.605 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_24=0.6, J_CHICKENPOX_28=0.6, MIME_BASE64_BLANKS=0.041, MIME_BASE64_TEXT=1.753, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vgWRibYMBQRP for ; Sat, 21 Jun 2008 07:56:46 -0700 (PDT) Received: from smtp04.bis.na.blackberry.com (smtp04.bis.na.blackberry.com [216.9.248.51]) by core3.amsl.com (Postfix) with ESMTP id 2E6693A67B1 for ; Sat, 21 Jun 2008 07:56:45 -0700 (PDT) Received: from bda379.bisx.prod.on.blackberry (bda379.bisx.prod.on.blackberry [172.20.234.79]) by srs.bis.na.blackberry.com (8.13.7 TEAMON/8.13.7) with ESMTP id m5LEukBa001119; Sat, 21 Jun 2008 14:56:46 GMT Received: from bda379.bisx.prod.on.blackberry (localhost.localdomain [127.0.0.1]) by bda379.bisx.prod.on.blackberry (8.13.7 TEAMON/8.13.7) with ESMTP id m5LEuhHq016369; Sat, 21 Jun 2008 14:56:43 GMT X-rim-org-msg-ref-id: 561088202 Message-ID: <561088202-1214060202-cardhu_decombobulator_blackberry.rim.net-153148407-@bxe014.bisx.prod.on.blackberry> X-Priority: Normal References: <20080620123001.C2BDE3A6A74@core3.amsl.com><1214056144.3904.1693.camel@hurina><1214058346.3904.1702.camel@hurina> In-Reply-To: <1214058346.3904.1702.camel@hurina> Sensitivity: Normal Importance: Normal To: "Timo Sirainen" From: eburger@standardstrack.com Date: Sat, 21 Jun 2008 14:56:53 +0000 MIME-Version: 1.0 Cc: lemonade Subject: Re: [lemonade] I-D Action:draft-ietf-lemonade-profile-bis-09.txt X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: eburger@standardstrack.com List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org Why make the server that much more complex and required to hold that much more state? Sent from my Verizon Wireless BlackBerry -----Original Message----- From: Timo Sirainen Date: Sat, 21 Jun 2008 17:25:46 To:Mark Crispin Cc:lemonade Subject: Re: [lemonade] I-D Action:draft-ietf-lemonade-profile-bis-09.txt On Sat, 2008-06-21 at 07:22 -0700, Mark Crispin wrote: > > "If a client issues a CAPABILITY command depite having already received > > the capability in the greeting, the server MAY omit the CAPABILITY > > response from the LOGIN/AUTHENTICATE commands." > > This is a very bad idea. It makes assumptions about the client which are not necessarily the case. Even if the client didn't ignore them, what's the point of sending the same CAPABILITY reply to the client twice? (Assuming of course it doesn't change. If it does change, then sure it should be sent.) _______________________________________________ lemonade mailing list lemonade@ietf.org https://www.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade _______________________________________________ lemonade mailing list lemonade@ietf.org https://www.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Sat Jun 21 08:04:32 2008 Return-Path: X-Original-To: lemonade-archive@optimus.ietf.org Delivered-To: ietfarch-lemonade-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4FDA63A68D9; Sat, 21 Jun 2008 08:04:32 -0700 (PDT) X-Original-To: lemonade@core3.amsl.com Delivered-To: lemonade@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C8D123A680D for ; Sat, 21 Jun 2008 08:04:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.669 X-Spam-Level: X-Spam-Status: No, score=-5.669 tagged_above=-999 required=5 tests=[AWL=-0.466, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yTmWS97xrflS for ; Sat, 21 Jun 2008 08:04:30 -0700 (PDT) Received: from dovecot.org (dovecot.org [82.118.211.50]) by core3.amsl.com (Postfix) with ESMTP id D2D533A6783 for ; Sat, 21 Jun 2008 08:04:29 -0700 (PDT) Received: from [192.168.10.2] (xdsl-177-118.nblnetworks.fi [217.30.177.118]) by dovecot.org (Postfix) with ESMTP id 8A31A1647247 for ; Sat, 21 Jun 2008 18:04:02 +0300 (EEST) From: Timo Sirainen To: lemonade@ietf.org In-Reply-To: References: <20080620123001.C2BDE3A6A74@core3.amsl.com> <1214056144.3904.1693.camel@hurina> Date: Sat, 21 Jun 2008 18:04:02 +0300 Message-Id: <1214060642.3904.1723.camel@hurina> Mime-Version: 1.0 X-Mailer: Evolution 2.22.1 Subject: Re: [lemonade] I-D Action:draft-ietf-lemonade-profile-bis-09.txt X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1743335256==" Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org --===============1743335256== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-VMw0W4leJT66NObW3g07" --=-VMw0W4leJT66NObW3g07 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Sat, 2008-06-21 at 16:44 +0200, Arnt Gulbrandsen wrote: > Timo Sirainen writes: > > Since some older clients want to issue CAPABILITY command always and=20 > > just ignore the capabilities sent in greeting/LOGIN/AUTHENTICATE=20 > > replies, [,,,] >=20 > Pretty much all older clients need some sort of change to take advantage=20 > of the lemonade goodies. A bigger change than learning to parse the=20 > CAPABILITY response-code. That's kind of the point. To write a Lemonade-compliant IMAP server I'd now have to send useless data to (a lot of) existing non-Lemonade clients. Another try at rewording what I meant: "CAPABILITY response code MAY be omitted from LOGIN/AUTHENTICATE command response if an equivalent CAPABILITY was already sent to the client, for example due to a CAPABILITY command or if the full CAPABILITY was already sent in the banner. STARTTLS however resets this capability tracking. CAPABILITY replies are equivalent if after removing capabilities that are relevant only in pre-authenticated state (e.g. AUTH=3D*, STARTTLS) they have exactly the same capabilities left." That brings to my mind though: Should CAPABILITY reponse code also be a "MUST be sent" for STARTTLS reply? RFC 3501 already says the CAPABILITY command SHOULD be reissued. --=-VMw0W4leJT66NObW3g07 Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQBIXRhiyUhSUUBViskRAtIfAJ4yqvwr09+y+p89toNHTcE4QM6x+gCcCZ+5 giJOFQslKsNzrX/iN/I+C5g= =w0Ka -----END PGP SIGNATURE----- --=-VMw0W4leJT66NObW3g07-- --===============1743335256== 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://www.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade --===============1743335256==-- From lemonade-bounces@ietf.org Sat Jun 21 08:15:49 2008 Return-Path: X-Original-To: lemonade-archive@optimus.ietf.org Delivered-To: ietfarch-lemonade-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 25C623A6822; Sat, 21 Jun 2008 08:15:49 -0700 (PDT) X-Original-To: lemonade@core3.amsl.com Delivered-To: lemonade@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4B9AD3A6822 for ; Sat, 21 Jun 2008 08:15:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.274 X-Spam-Level: X-Spam-Status: No, score=-6.274 tagged_above=-999 required=5 tests=[AWL=0.326, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id peHOqI-CYaW1 for ; Sat, 21 Jun 2008 08:15:46 -0700 (PDT) Received: from dovecot.org (dovecot.org [82.118.211.50]) by core3.amsl.com (Postfix) with ESMTP id 676133A6783 for ; Sat, 21 Jun 2008 08:15:46 -0700 (PDT) Received: from [192.168.10.2] (xdsl-177-118.nblnetworks.fi [217.30.177.118]) by dovecot.org (Postfix) with ESMTP id A81241647247 for ; Sat, 21 Jun 2008 18:15:19 +0300 (EEST) From: Timo Sirainen To: lemonade@ietf.org In-Reply-To: References: <20080620123001.C2BDE3A6A74@core3.amsl.com> <1214056144.3904.1693.camel@hurina> <1214058346.3904.1702.camel@hurina> Date: Sat, 21 Jun 2008 18:15:19 +0300 Message-Id: <1214061319.3904.1730.camel@hurina> Mime-Version: 1.0 X-Mailer: Evolution 2.22.1 Subject: Re: [lemonade] I-D Action:draft-ietf-lemonade-profile-bis-09.txt X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0225567112==" Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org --===============0225567112== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-ZUJlm9RJ8FFFc10PssaQ" --=-ZUJlm9RJ8FFFc10PssaQ Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Sat, 2008-06-21 at 07:55 -0700, Mark Crispin wrote: > >>> "If a client issues a CAPABILITY command depite having already receiv= ed > >>> the capability in the greeting, the server MAY omit the CAPABILITY > >>> response from the LOGIN/AUTHENTICATE commands." > >> This is a very bad idea. It makes assumptions about the client which a= re not necessarily the case. > > Even if the client didn't ignore them, what's the point of sending the > > same CAPABILITY reply to the client twice? (Assuming of course it > > doesn't change. If it does change, then sure it should be sent.) >=20 > Are you, personally, willing to guarantee that this proposed > additional (and IMHO pointless) complexity will never cause a problem, > now and in the future? >=20 > It IS additional complexity. It is an added behavior rule, with > implications for both server and client. The sole apparent purpose is > to save a few octets of network traffic. The cost is that misbehavior > by either client or server will cause bugs. Well, yes, it is extra complexity.. Maybe it could be said somehow in a bit more simple way that would give the same result for Lemonade clients. But I guess it doesn't really matter, since the environments where those few extra bytes might matter should probably be using Lemonade anyway. But what about the STARTTLS reply having CAPABILITY? --=-ZUJlm9RJ8FFFc10PssaQ Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQBIXRsHyUhSUUBViskRArWIAKCKt3/0S7EwDInqdVgOs8M+9WCBsACffgtC GrHHqh/C7Gy0lgp/EbzfmjI= =u5O5 -----END PGP SIGNATURE----- --=-ZUJlm9RJ8FFFc10PssaQ-- --===============0225567112== 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://www.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade --===============0225567112==-- From lemonade-bounces@ietf.org Sat Jun 21 08:26:31 2008 Return-Path: X-Original-To: lemonade-archive@optimus.ietf.org Delivered-To: ietfarch-lemonade-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 12EEC3A6955; Sat, 21 Jun 2008 08:26:31 -0700 (PDT) X-Original-To: lemonade@core3.amsl.com Delivered-To: lemonade@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 392A43A6955 for ; Sat, 21 Jun 2008 08:26:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.328 X-Spam-Level: X-Spam-Status: No, score=-6.328 tagged_above=-999 required=5 tests=[AWL=0.271, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WQuEwtoS8C+R for ; Sat, 21 Jun 2008 08:26:28 -0700 (PDT) Received: from dovecot.org (dovecot.org [82.118.211.50]) by core3.amsl.com (Postfix) with ESMTP id 60FB93A6822 for ; Sat, 21 Jun 2008 08:26:28 -0700 (PDT) Received: from [192.168.10.2] (xdsl-177-118.nblnetworks.fi [217.30.177.118]) by dovecot.org (Postfix) with ESMTP id A84091647247 for ; Sat, 21 Jun 2008 18:26:01 +0300 (EEST) From: Timo Sirainen To: lemonade@ietf.org In-Reply-To: <1214061319.3904.1730.camel@hurina> References: <20080620123001.C2BDE3A6A74@core3.amsl.com> <1214056144.3904.1693.camel@hurina> <1214058346.3904.1702.camel@hurina> <1214061319.3904.1730.camel@hurina> Date: Sat, 21 Jun 2008 18:26:01 +0300 Message-Id: <1214061961.3904.1733.camel@hurina> Mime-Version: 1.0 X-Mailer: Evolution 2.22.1 Subject: Re: [lemonade] I-D Action:draft-ietf-lemonade-profile-bis-09.txt X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1051251357==" Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org --===============1051251357== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-yRZ/eyrPnEYflXbSEdKb" --=-yRZ/eyrPnEYflXbSEdKb Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Sat, 2008-06-21 at 18:15 +0300, Timo Sirainen wrote: > But what about the STARTTLS reply having CAPABILITY? I forgot that the tagged OK was sent before TLS negotiation was started, not after. I guess that can't be helped either then, so just forget about everything I said in this thread.. --=-yRZ/eyrPnEYflXbSEdKb Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQBIXR2JyUhSUUBViskRArWpAKCLPUNh4ePQTHQjsDnNBOQtmpzWnwCfTcgF pRNe7o4i26+dqmT18YGsKbk= =F157 -----END PGP SIGNATURE----- --=-yRZ/eyrPnEYflXbSEdKb-- --===============1051251357== 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://www.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade --===============1051251357==-- From lemonade-bounces@ietf.org Sat Jun 21 09:25:13 2008 Return-Path: X-Original-To: lemonade-archive@optimus.ietf.org Delivered-To: ietfarch-lemonade-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8B3D73A6980; Sat, 21 Jun 2008 09:25:13 -0700 (PDT) X-Original-To: lemonade@core3.amsl.com Delivered-To: lemonade@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8C4893A6980 for ; Sat, 21 Jun 2008 09:25:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.577 X-Spam-Level: X-Spam-Status: No, score=-2.577 tagged_above=-999 required=5 tests=[AWL=-0.022, BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2JSW0R7lq4Z6 for ; Sat, 21 Jun 2008 09:25:11 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id 7DB7D3A6971 for ; Sat, 21 Jun 2008 09:25:10 -0700 (PDT) Received: from [192.168.0.2] ((unknown) [62.3.217.253]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Sat, 21 Jun 2008 17:25:13 +0100 X-SMTP-Protocol-Errors: NORDNS Message-ID: <485CF694.6080407@isode.com> Date: Sat, 21 Jun 2008 13:39:48 +0100 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: Timo Sirainen References: <8B9B8F32-8DEF-40B9-992E-9337FB7AE344@standardstrack.com> <1210951366.9518.654.camel@hurina> <48312F7D.8090103@isode.com> <1211191304.9518.755.camel@hurina> <4835D000.4080808@isode.com> <1211745339.3904.166.camel@hurina> <483BAB35.2080806@isode.com> <1B7D968F-7A77-40FC-AFD6-ADF3C2826822@iki.fi> <484657A5.5070202@isode.com> <1212595278.3904.735.camel@hurina> <1212675916.3904.858.camel@hurina> <4850501E.2080504@isode.com> <1213267448.3904.1211.camel@hurina> In-Reply-To: <1213267448.3904.1211.camel@hurina> MIME-Version: 1.0 Cc: lemonade Subject: Re: [lemonade] WGLC NOTIFY X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org Hi Timo: Timo Sirainen wrote: >On Wed, 2008-06-11 at 23:22 +0100, Alexey Melnikov wrote: > > [...] >>>The closest default IMAP behavior would be (MessageNew FlagChange). >>>Most servers delay sending the changes until a command is started, >>>but that's not required by RFC 3501 so I don't think it matters. >>> >>>Perhaps MessageNew should be always enabled? >>> >>> >>This would disallow the NOTIFY NONE behavior. >> >> >What if there was first a big switch between "NONE" vs. "something" and >then some finer switches under "something": > >a) NONE - nothing sent at all. > >b) >- MessageNew always sent immediately >- MessageExpunge always sent, but could be either delayed or immediate >- Flags, annotations, etc. are optionally sent, but if they are they're >always immediate > >I guess the b) option could be done by specifying that unless NONE is >used, MessageNew is always used regardless of whether it's explicitly >specified or not. > >It probably would be cleaner if the entire syntax was changed a bit: > >NOTIFY SELECTED [(optionals) [(fetch attributes)]] > >NOTIFY SELECTED none > - nothing sent >NOTIFY SELECTED delayed > - delayed expunges, immediate EXISTS, no flag changes >NOTIFY SELECTED delayed (FlagChange) > - delayed expunges, immediate EXISTS and flag changes >NOTIFY SELECTED immediate (FlagChange) (UID FLAGS) > - immediate expunges, EXISTS and flag changes, new messages return >FETCH (UID FLAGS) >NOTIFY SELECTED immediate () (UID FLAGS) > - no flags, immediate others > Timo Sirainen wrote: >So I wouldn't mind if NOTIFY had a big switch that >worked like: > >a) Immediate: Send expunges, exists and everything else immediately to >client > >b) Delayed: Server is allowed (but not required) to delay all events >until a command is executed that allows returning expunges (usually >IDLE, but also others) > I've changed the definition of "SELECTED" to "SELECT immediate" as you defined above. I've also added SELECTED-DELAYED, which corresponds to "SELECTED delayed" in your proposal. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Sat Jun 21 09:25:15 2008 Return-Path: X-Original-To: lemonade-archive@optimus.ietf.org Delivered-To: ietfarch-lemonade-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A9DF83A69A1; Sat, 21 Jun 2008 09:25:15 -0700 (PDT) X-Original-To: lemonade@core3.amsl.com Delivered-To: lemonade@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BF8333A698C for ; Sat, 21 Jun 2008 09:25:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.592 X-Spam-Level: X-Spam-Status: No, score=-2.592 tagged_above=-999 required=5 tests=[AWL=0.007, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bD1uu6wYoiXO for ; Sat, 21 Jun 2008 09:25:13 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id BE30B3A6971 for ; Sat, 21 Jun 2008 09:25:12 -0700 (PDT) Received: from [192.168.0.2] ((unknown) [62.3.217.253]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Sat, 21 Jun 2008 17:25:15 +0100 X-SMTP-Protocol-Errors: NORDNS Message-ID: <485D085E.60007@isode.com> Date: Sat, 21 Jun 2008 14:55:42 +0100 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: Lemonade WG MIME-Version: 1.0 Subject: [lemonade] IMAP NOTIFY issue X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org Section 6 currently contains the following paragraph: If for any given event type the client specifies monitoring of the same mailbox several times (using the same or different mailbox specifications), the first specification wins. The paragraph quoted above is followed by: Note that for different event types different s can apply to the same mailbox. The following example demonstrates this. In this example, MessageNew and MessageExpunge events are reported for INBOX due to the first . SubscriptionChange event will also be reported for INBOX due to the second . So, if we have a NOTIFY SET command: C: a notify set (mailboxes INBOX (SubscriptionChange Messagenew messageExpunge)) (personal (SubscriptionChange)) the first quoted paragraph seem to be saying that SubscriptionChange, MessageNew and MessageExpunge events would be returned for INBOX and the "personal" mailbox selector wouldn't apply to INBOX, because SubscriptionChange is already specified in "mailboxes INBOX". But, NOTIFY has no way to exclude mailboxes, so this makes no much sense. So, I've deleted the first quoted paragraph and changed the first sentence of the second quoted paragraph to read: Note that multiple s can apply to the same mailbox. (i.e. I've deleted "for different event types" and changed "diffent" to "multiple") If you think this change is an error, please let me know. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Sat Jun 21 09:39:36 2008 Return-Path: X-Original-To: lemonade-archive@optimus.ietf.org Delivered-To: ietfarch-lemonade-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BAA753A684F; Sat, 21 Jun 2008 09:39:36 -0700 (PDT) X-Original-To: lemonade@core3.amsl.com Delivered-To: lemonade@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 79C983A684F for ; Sat, 21 Jun 2008 09:39:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.594 X-Spam-Level: X-Spam-Status: No, score=-2.594 tagged_above=-999 required=5 tests=[AWL=0.006, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NMM-dJk4k0+5 for ; Sat, 21 Jun 2008 09:39:35 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id A0C5E3A67B1 for ; Sat, 21 Jun 2008 09:39:35 -0700 (PDT) Received: from [192.168.0.2] ((unknown) [62.3.217.253]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Sat, 21 Jun 2008 17:39:38 +0100 X-SMTP-Protocol-Errors: NORDNS Message-ID: <485D2EC6.9010603@isode.com> Date: Sat, 21 Jun 2008 17:39:34 +0100 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: Lemonade WG References: <48505164.6080809@isode.com> In-Reply-To: <48505164.6080809@isode.com> MIME-Version: 1.0 Subject: Re: [lemonade] Status of the IMAP NOTIFY document X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org Alexey Melnikov wrote: > 2). What happens to message events in the currently selected mailbox > if NOTIFY SET is used, but SELECTED isn't specified? > > I think Timo suggested to use the default behavior (i.e. before NOTIFY > SET is specified). I tend to think that this might be a reasonable > choice and would cover some of the use cases proposed by Timo. I've changed my mind on this: due to other changes (in particular addition of SELECTED-DELAYED) I think it makes more sense to just prohibit the server to send any changes for omitted events. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Sat Jun 21 16:27:40 2008 Return-Path: X-Original-To: lemonade-archive@optimus.ietf.org Delivered-To: ietfarch-lemonade-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8B9163A69A6; Sat, 21 Jun 2008 16:27:40 -0700 (PDT) X-Original-To: lemonade@core3.amsl.com Delivered-To: lemonade@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CE75C3A6910 for ; Sat, 21 Jun 2008 16:27:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.367 X-Spam-Level: X-Spam-Status: No, score=-6.367 tagged_above=-999 required=5 tests=[AWL=0.232, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XQ3KgX8A827V for ; Sat, 21 Jun 2008 16:27:38 -0700 (PDT) Received: from dovecot.org (dovecot.org [82.118.211.50]) by core3.amsl.com (Postfix) with ESMTP id 940003A6837 for ; Sat, 21 Jun 2008 16:27:37 -0700 (PDT) Received: from [192.168.10.200] (xdsl-177-118.nblnetworks.fi [217.30.177.118]) by dovecot.org (Postfix) with ESMTP id 51CFF16471E3; Sun, 22 Jun 2008 02:27:08 +0300 (EEST) Message-Id: <793CD408-97FA-4DB3-9633-2E2C8B6DB9D0@iki.fi> From: Timo Sirainen To: Alexey Melnikov In-Reply-To: <485CF694.6080407@isode.com> Mime-Version: 1.0 (Apple Message framework v924) Date: Sun, 22 Jun 2008 02:27:08 +0300 References: <8B9B8F32-8DEF-40B9-992E-9337FB7AE344@standardstrack.com> <1210951366.9518.654.camel@hurina> <48312F7D.8090103@isode.com> <1211191304.9518.755.camel@hurina> <4835D000.4080808@isode.com> <1211745339.3904.166.camel@hurina> <483BAB35.2080806@isode.com> <1B7D968F-7A77-40FC-AFD6-ADF3C2826822@iki.fi> <484657A5.5070202@isode.com> <1212595278.3904.735.camel@hurina> <1212675916.3904.858.camel@hurina> <4850501E.2080504@isode.com> <1213267448.3904.1211.camel@hurina> <485CF694.6080407@isode.com> X-Pgp-Agent: GPGMail d51 (Leopard) X-Mailer: Apple Mail (2.924) Cc: lemonade Subject: Re: [lemonade] WGLC NOTIFY X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1361504148==" Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============1361504148== Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-23--439572683" Content-Transfer-Encoding: 7bit This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-23--439572683 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit On Jun 21, 2008, at 3:39 PM, Alexey Melnikov wrote: > Timo Sirainen wrote: > >> So I wouldn't mind if NOTIFY had a big switch that worked like: >> >> a) Immediate: Send expunges, exists and everything else immediately >> to client >> >> b) Delayed: Server is allowed (but not required) to delay all >> events until a command is executed that allows returning expunges >> (usually IDLE, but also others) >> > I've changed the definition of "SELECTED" to "SELECT immediate" as > you defined above. I've also added SELECTED-DELAYED, which > corresponds to "SELECTED delayed" in your proposal. Sounds good. Is there also something about MessageExpunge being unnecessary (or even illegal?) in SELECTED/SELECTED-DELAYED and MessageNew being unnecessary (or even illegal?) unless it specifies FETCH options? --Apple-Mail-23--439572683 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig content-transfer-encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) iEYEARECAAYFAkhdjkwACgkQyUhSUUBVislbUACeNX4jCB1UTzQbHavHINxU00uI KnkAoJs9jNmy0aLfbuy5YaFF0oI8StGM =V3ae -----END PGP SIGNATURE----- --Apple-Mail-23--439572683-- --===============1361504148== 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://www.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade --===============1361504148==-- From lemonade-bounces@ietf.org Sat Jun 21 16:33:11 2008 Return-Path: X-Original-To: lemonade-archive@optimus.ietf.org Delivered-To: ietfarch-lemonade-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B71A13A69AC; Sat, 21 Jun 2008 16:33:11 -0700 (PDT) X-Original-To: lemonade@core3.amsl.com Delivered-To: lemonade@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 14EC63A69A4 for ; Sat, 21 Jun 2008 16:33:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.396 X-Spam-Level: X-Spam-Status: No, score=-6.396 tagged_above=-999 required=5 tests=[AWL=0.203, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SGjTXHwX8Q0P for ; Sat, 21 Jun 2008 16:33:03 -0700 (PDT) Received: from dovecot.org (dovecot.org [82.118.211.50]) by core3.amsl.com (Postfix) with ESMTP id A63AE3A6837 for ; Sat, 21 Jun 2008 16:33:03 -0700 (PDT) Received: from [192.168.10.200] (xdsl-177-118.nblnetworks.fi [217.30.177.118]) by dovecot.org (Postfix) with ESMTP id ACE5116471E3; Sun, 22 Jun 2008 02:32:37 +0300 (EEST) Message-Id: From: Timo Sirainen To: Alexey Melnikov In-Reply-To: <485D2EC6.9010603@isode.com> Mime-Version: 1.0 (Apple Message framework v924) Date: Sun, 22 Jun 2008 02:32:37 +0300 References: <48505164.6080809@isode.com> <485D2EC6.9010603@isode.com> X-Pgp-Agent: GPGMail d51 (Leopard) X-Mailer: Apple Mail (2.924) Cc: Lemonade WG Subject: Re: [lemonade] Status of the IMAP NOTIFY document X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0541895760==" Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============0541895760== Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-24--439243378" Content-Transfer-Encoding: 7bit This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-24--439243378 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit On Jun 21, 2008, at 7:39 PM, Alexey Melnikov wrote: > Alexey Melnikov wrote: > >> 2). What happens to message events in the currently selected >> mailbox if NOTIFY SET is used, but SELECTED isn't specified? >> >> I think Timo suggested to use the default behavior (i.e. before >> NOTIFY SET is specified). I tend to think that this might be a >> reasonable choice and would cover some of the use cases proposed by >> Timo. > > I've changed my mind on this: due to other changes (in particular > addition of SELECTED-DELAYED) I think it makes more sense to just > prohibit the server to send any changes for omitted events. Do you mean if NOTIFY SET is used but SELECTED/SELECTED-DELAYED isn't, it would default to SELECTED NONE? That'd be fine with me. --Apple-Mail-24--439243378 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig content-transfer-encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) iEYEARECAAYFAkhdj5UACgkQyUhSUUBVisk7uQCfTx1iwrMotqCPgVL0txK7khbg gT4AmgIfJUBZMh28mSC+aBY4TvhEgmkm =iGe2 -----END PGP SIGNATURE----- --Apple-Mail-24--439243378-- --===============0541895760== 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://www.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade --===============0541895760==-- From lemonade-bounces@ietf.org Sun Jun 22 07:28:44 2008 Return-Path: X-Original-To: lemonade-archive@optimus.ietf.org Delivered-To: ietfarch-lemonade-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0829E3A69D9; Sun, 22 Jun 2008 07:28:44 -0700 (PDT) X-Original-To: lemonade@core3.amsl.com Delivered-To: lemonade@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8E62F3A69F0 for ; Sun, 22 Jun 2008 07:28:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.596 X-Spam-Level: X-Spam-Status: No, score=-2.596 tagged_above=-999 required=5 tests=[AWL=0.003, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vAM4ZV25aMcq for ; Sun, 22 Jun 2008 07:28:41 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id 6F8763A69D9 for ; Sun, 22 Jun 2008 07:28:41 -0700 (PDT) Received: from [192.168.0.2] ((unknown) [62.3.217.253]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Sun, 22 Jun 2008 15:28:46 +0100 X-SMTP-Protocol-Errors: NORDNS Message-ID: <485E6198.3090009@isode.com> Date: Sun, 22 Jun 2008 15:28:40 +0100 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: Timo Sirainen References: <48505164.6080809@isode.com> <485D2EC6.9010603@isode.com> In-Reply-To: MIME-Version: 1.0 Cc: Lemonade WG Subject: Re: [lemonade] Status of the IMAP NOTIFY document X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org Timo Sirainen wrote: > On Jun 21, 2008, at 7:39 PM, Alexey Melnikov wrote: > >> Alexey Melnikov wrote: >> >>> 2). What happens to message events in the currently selected >>> mailbox if NOTIFY SET is used, but SELECTED isn't specified? >>> >>> I think Timo suggested to use the default behavior (i.e. before >>> NOTIFY SET is specified). I tend to think that this might be a >>> reasonable choice and would cover some of the use cases proposed by >>> Timo. >> >> I've changed my mind on this: due to other changes (in particular >> addition of SELECTED-DELAYED) I think it makes more sense to just >> prohibit the server to send any changes for omitted events. > > Do you mean if NOTIFY SET is used but SELECTED/SELECTED-DELAYED > isn't, it would default to SELECTED NONE? Yes. > That'd be fine with me. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Tue Jun 24 04:18:03 2008 Return-Path: X-Original-To: lemonade-archive@optimus.ietf.org Delivered-To: ietfarch-lemonade-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 07BF33A68C5; Tue, 24 Jun 2008 04:18:03 -0700 (PDT) X-Original-To: lemonade@core3.amsl.com Delivered-To: lemonade@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F06FE3A68C5 for ; Tue, 24 Jun 2008 04:18:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.74 X-Spam-Level: X-Spam-Status: No, score=-0.74 tagged_above=-999 required=5 tests=[BAYES_20=-0.74] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NEDrywnG+aTQ for ; Tue, 24 Jun 2008 04:18:01 -0700 (PDT) Received: from mail2.pvanhoof.be (pvanhoof.freax.org [86.39.154.67]) by core3.amsl.com (Postfix) with ESMTP id D452E3A688A for ; Tue, 24 Jun 2008 04:18:00 -0700 (PDT) Received: from [192.168.10.162] (d54C0C06D.access.telenet.be [84.192.192.109]) (using SSLv3 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail2.pvanhoof.be (Postfix) with ESMTP id 34645A7F85 for ; Tue, 24 Jun 2008 13:02:42 +0200 (CEST) From: Philip Van Hoof To: Enhancements to Internet email to support diverse service enivronments Date: Tue, 24 Jun 2008 13:17:51 +0200 Message-Id: <1214306271.6138.18.camel@nerts> Mime-Version: 1.0 X-Mailer: Evolution 2.22.2 Subject: [lemonade] Why we should let the IMAP specification become more rich, rather than poor X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org This is a personal opinion. With Lemonade we finally have the opportunity to improve the IMAP spec and to let IMAP servers advertise richness of features in a marketing- meaningful way. My opinion is that we have seen four kinds of IMAP servers: - Free software ones that get a lot right - Free software ones that get most (or at least a lot) wrong - Commercial ones that get most right - Commercial ones that are actually trying to sell their closed protocol instead, but offer a crippled "old IMAP" interface for marketing purposes (we do IMAP too, look at us!) For several years it was possible to say that for example Google's recent IMAP server offering is a rather poor IMAP server because UNSELECT, IDLE, NAMESPACE, QUOTA, XLIST, CHILDREN and something weird called XYZZY is not really that much of a big deal for a modern IMAP server ... nowadays. My guess is that this XYZZY is that item #4 in the list above: XYZZY was a magic word used in one of the earliest computer adventure games - Colossal Cavern. It would transport you between two different parts of the map. Nowadays you can, however funny XYZZY is, effectively say that Google's IMAP server is just not a Lemonade-ready IMAP server: - No CONDSTORE, no RSYNC - No CATENATE - No UIDPLUS Let's hope that for marketing this will be meaningful someday and that we that way can convince vendors like Google to do a better job. ps. I don't care how good the extensions behind XYZZY are. Not specified in an open way means that they don't exist for my E-mail clients. -- Philip Van Hoof, freelance software developer home: me at pvanhoof dot be gnome: pvanhoof at gnome dot org http://pvanhoof.be/blog http://codeminded.be _______________________________________________ lemonade mailing list lemonade@ietf.org https://www.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Tue Jun 24 04:55:02 2008 Return-Path: X-Original-To: lemonade-archive@optimus.ietf.org Delivered-To: ietfarch-lemonade-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D9C243A69E8; Tue, 24 Jun 2008 04:55:02 -0700 (PDT) X-Original-To: lemonade@core3.amsl.com Delivered-To: lemonade@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E14BB3A69E8 for ; Tue, 24 Jun 2008 04:55:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.418 X-Spam-Level: X-Spam-Status: No, score=-6.418 tagged_above=-999 required=5 tests=[AWL=0.181, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AIpMaJeDsD3H for ; Tue, 24 Jun 2008 04:55:00 -0700 (PDT) Received: from dovecot.org (dovecot.org [82.118.211.50]) by core3.amsl.com (Postfix) with ESMTP id BE0153A69C2 for ; Tue, 24 Jun 2008 04:55:00 -0700 (PDT) Received: from [192.168.10.2] (xdsl-177-118.nblnetworks.fi [217.30.177.118]) by dovecot.org (Postfix) with ESMTP id D2ED616471E2; Tue, 24 Jun 2008 14:54:27 +0300 (EEST) From: Timo Sirainen To: Philip Van Hoof In-Reply-To: <1214306271.6138.18.camel@nerts> References: <1214306271.6138.18.camel@nerts> Date: Tue, 24 Jun 2008 14:54:27 +0300 Message-Id: <1214308467.3904.1826.camel@hurina> Mime-Version: 1.0 X-Mailer: Evolution 2.22.1 Cc: Enhancements to Internet email to support diverse service enivronments Subject: Re: [lemonade] Why we should let the IMAP specification become more rich, rather than poor X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2082293774==" Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org --===============2082293774== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-xj2Wu3a9rNjt3udAiZ23" --=-xj2Wu3a9rNjt3udAiZ23 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Tue, 2008-06-24 at 13:17 +0200, Philip Van Hoof wrote: > This is a personal opinion. >=20 > With Lemonade we finally have the opportunity to improve the IMAP spec > and to let IMAP servers advertise richness of features in a marketing- > meaningful way. >=20 > My opinion is that we have seen four kinds of IMAP servers: >=20 > - Free software ones that get a lot right > - Free software ones that get most (or at least a lot) wrong > - Commercial ones that get most right > - Commercial ones that are actually trying to sell their closed protocol > instead, but offer a crippled "old IMAP" interface for marketing > purposes (we do IMAP too, look at us!) I had hoped that maybe at some point my imaptest tool's results could motivate at least some servers to get themselves more compliant: http://imapwiki.org/ImapTest/ServerStatus The "failures" number may be somewhat inflated for some servers, because the tests don't currently always uniquely test a single thing, but for example if \Recent flag handling isn't correct multiple tests can fail. Also the 34 as maximum should probably be changed at some point to the actual number of commands that tested successfully, instead of the number of files that tested things (which contain about 1-30 tests each). I was also planning on writing tests for Lemonade extensions at some point, but since I haven't implemented half of Lemonade yet myself there hasn't been much motivation yet. --=-xj2Wu3a9rNjt3udAiZ23 Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQBIYOBzyUhSUUBViskRAg7KAKCm3FyzAga5I6PA4TSd5+PE5gJdUACgnjgy nT2EyaGplLz8h/L7wtI7ZZQ= =4fg5 -----END PGP SIGNATURE----- --=-xj2Wu3a9rNjt3udAiZ23-- --===============2082293774== 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://www.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade --===============2082293774==-- From lemonade-bounces@ietf.org Tue Jun 24 06:02:02 2008 Return-Path: X-Original-To: lemonade-archive@optimus.ietf.org Delivered-To: ietfarch-lemonade-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 559BC3A699A; Tue, 24 Jun 2008 06:02:02 -0700 (PDT) X-Original-To: lemonade@core3.amsl.com Delivered-To: lemonade@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0374F3A6994 for ; Tue, 24 Jun 2008 06:02:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.67 X-Spam-Level: X-Spam-Status: No, score=-1.67 tagged_above=-999 required=5 tests=[AWL=0.930, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p3-kPe2fIAj2 for ; Tue, 24 Jun 2008 06:02:00 -0700 (PDT) Received: from mail2.pvanhoof.be (pvanhoof.freax.org [86.39.154.67]) by core3.amsl.com (Postfix) with ESMTP id E33D33A6920 for ; Tue, 24 Jun 2008 06:01:59 -0700 (PDT) Received: from [192.168.10.162] (d54C0C06D.access.telenet.be [84.192.192.109]) (using SSLv3 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail2.pvanhoof.be (Postfix) with ESMTP id 58E18A7F84 for ; Tue, 24 Jun 2008 14:46:49 +0200 (CEST) From: Philip Van Hoof To: Enhancements to Internet email to support diverse service enivronments In-Reply-To: <1214306271.6138.18.camel@nerts> References: <1214306271.6138.18.camel@nerts> Date: Tue, 24 Jun 2008 15:01:56 +0200 Message-Id: <1214312516.6138.21.camel@nerts> Mime-Version: 1.0 X-Mailer: Evolution 2.22.2 Subject: Re: [lemonade] Why we should let the IMAP specification become more rich, rather than poor X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org On Tue, 2008-06-24 at 13:17 +0200, Philip Van Hoof wrote: > ps. I don't care how good the extensions behind XYZZY are. Not specified > in an open way means that they don't exist for my E-mail clients. Would it make sense to claim in the RFC that you MUST NOT call yourself an IMAP server if you advertise capabilities that are not publicized as either RFC or in proposal at IETF? Opinion: For me that would make a lot of sense. I don't really like how Google is polluting the CAPABILITY line with their closed things (again, no matter how funny they pick the capability names). They can call it GMAP, whatever. -- Philip Van Hoof, freelance software developer home: me at pvanhoof dot be gnome: pvanhoof at gnome dot org http://pvanhoof.be/blog http://codeminded.be _______________________________________________ lemonade mailing list lemonade@ietf.org https://www.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Tue Jun 24 08:25:08 2008 Return-Path: X-Original-To: lemonade-archive@optimus.ietf.org Delivered-To: ietfarch-lemonade-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E57B828C100; Tue, 24 Jun 2008 08:25:08 -0700 (PDT) X-Original-To: lemonade@core3.amsl.com Delivered-To: lemonade@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 977BD28C0F8 for ; Tue, 24 Jun 2008 08:25:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uHls9syrGgku for ; Tue, 24 Jun 2008 08:25:04 -0700 (PDT) Received: from cox.com (post4.cox.com [24.248.72.37]) by core3.amsl.com (Postfix) with ESMTP id 4272828C0FA for ; Tue, 24 Jun 2008 08:25:03 -0700 (PDT) Received: from ([192.168.72.254]) by post4.cox.com with ESMTP id 5503597.39262892; Tue, 24 Jun 2008 11:24:39 -0400 Received: from CATL0MS21.CORP.COX.COM ([10.64.210.21]) by catl0ms23.CORP.COX.COM with Microsoft SMTPSVC(6.0.3790.3959); Tue, 24 Jun 2008 11:24:40 -0400 Received: from CATL0MS02.corp.cox.com ([10.62.210.88]) by CATL0MS21.CORP.COX.COM with Microsoft SMTPSVC(6.0.3790.3959); Tue, 24 Jun 2008 11:24:39 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 24 Jun 2008 11:24:39 -0400 Message-ID: In-Reply-To: <1214312516.6138.21.camel@nerts> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [lemonade] Why we should let the IMAP specification become morerich, rather than poor Thread-Index: AcjV+pad8xXWFzi6ShuxRHL/FV0o3wAE1SlA References: <1214306271.6138.18.camel@nerts> <1214312516.6138.21.camel@nerts> From: To: , X-OriginalArrivalTime: 24 Jun 2008 15:24:39.0882 (UTC) FILETIME=[6B572AA0:01C8D60E] Subject: Re: [lemonade] Why we should let the IMAP specification become morerich, rather than poor X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org An RFC/IETF proposal defines a particular usage and scope. Declaring negative definitions is out of scope Thanks, Bill Oxley Messaging Engineer Cox Communications -----Original Message----- From: lemonade-bounces@ietf.org [mailto:lemonade-bounces@ietf.org] On Behalf Of Philip Van Hoof Sent: Tuesday, June 24, 2008 9:02 AM To: Enhancements to Internet email to support diverse service enivronments Subject: Re: [lemonade] Why we should let the IMAP specification become morerich, rather than poor On Tue, 2008-06-24 at 13:17 +0200, Philip Van Hoof wrote: > ps. I don't care how good the extensions behind XYZZY are. Not specified > in an open way means that they don't exist for my E-mail clients. Would it make sense to claim in the RFC that you MUST NOT call yourself an IMAP server if you advertise capabilities that are not publicized as either RFC or in proposal at IETF? Opinion: For me that would make a lot of sense. I don't really like how Google is polluting the CAPABILITY line with their closed things (again, no matter how funny they pick the capability names). They can call it GMAP, whatever. -- Philip Van Hoof, freelance software developer home: me at pvanhoof dot be gnome: pvanhoof at gnome dot org http://pvanhoof.be/blog http://codeminded.be _______________________________________________ lemonade mailing list lemonade@ietf.org https://www.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade _______________________________________________ lemonade mailing list lemonade@ietf.org https://www.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Tue Jun 24 10:12:35 2008 Return-Path: X-Original-To: lemonade-archive@optimus.ietf.org Delivered-To: ietfarch-lemonade-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6A4A53A6945; Tue, 24 Jun 2008 10:12:35 -0700 (PDT) X-Original-To: lemonade@core3.amsl.com Delivered-To: lemonade@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3C4863A6945 for ; Tue, 24 Jun 2008 10:12:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.084 X-Spam-Level: X-Spam-Status: No, score=0.084 tagged_above=-999 required=5 tests=[AWL=1.207, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, HELO_MISMATCH_NET=0.611, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fOH4vExAnC6t for ; Tue, 24 Jun 2008 10:12:33 -0700 (PDT) Received: from turner.dave.cridland.net (dsl-217-155-137-60.zen.co.uk [217.155.137.60]) by core3.amsl.com (Postfix) with ESMTP id 09F673A69F4 for ; Tue, 24 Jun 2008 10:12:33 -0700 (PDT) Received: from peirce.dave.cridland.net ([217.155.137.61]) by turner.dave.cridland.net (submission) via TCP with ESMTPA id ; Mon, 23 Jun 2008 20:37:09 +0100 X-SMTP-Protocol-Errors: PIPELINING References: <20080620123001.C2BDE3A6A74@core3.amsl.com> <1214056144.3904.1693.camel@hurina> <1214058346.3904.1702.camel@hurina> In-Reply-To: MIME-Version: 1.0 Message-Id: <18699.1214249828.573595@peirce.dave.cridland.net> Date: Mon, 23 Jun 2008 20:37:08 +0100 From: Dave Cridland To: Mark Crispin Cc: Enhancements to Internet email to support diverse service enivronments , Timo Sirainen Subject: Re: [lemonade] I-D Action:draft-ietf-lemonade-profile-bis-09.txt X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org On Sat Jun 21 15:55:47 2008, Mark Crispin wrote: > Are you, personally, willing to guarantee that this proposed > additional (and IMHO pointless) complexity will never cause a > problem, now and in the future? > > FWIW, I'm not willing to guarantee it, without investing quite a bit of work which, I'd point out, saves no round-trips, and only a small amount of bandwidth for sub-optimal clients at startup. > It IS additional complexity. It is an added behavior rule, with > implications for both server and client. The sole apparent purpose > is to save a few octets of network traffic. The cost is that > misbehavior by either client or server will cause bugs. > > Agreed. Dave. -- Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@dave.cridland.net - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade _______________________________________________ lemonade mailing list lemonade@ietf.org https://www.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Tue Jun 24 10:19:33 2008 Return-Path: X-Original-To: lemonade-archive@optimus.ietf.org Delivered-To: ietfarch-lemonade-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C8A713A68C3; Tue, 24 Jun 2008 10:19:33 -0700 (PDT) X-Original-To: lemonade@core3.amsl.com Delivered-To: lemonade@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5BD983A68C3 for ; Tue, 24 Jun 2008 10:19:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.134 X-Spam-Level: X-Spam-Status: No, score=-2.134 tagged_above=-999 required=5 tests=[AWL=0.465, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C-CxmY7JhbrC for ; Tue, 24 Jun 2008 10:19:31 -0700 (PDT) Received: from mail2.pvanhoof.be (pvanhoof.freax.org [86.39.154.67]) by core3.amsl.com (Postfix) with ESMTP id 6A5863A683C for ; Tue, 24 Jun 2008 10:19:31 -0700 (PDT) Received: from [192.168.10.162] (d54C0C06D.access.telenet.be [84.192.192.109]) (using SSLv3 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail2.pvanhoof.be (Postfix) with ESMTP id CAF75A7F85; Tue, 24 Jun 2008 19:04:20 +0200 (CEST) From: Philip Van Hoof To: Dan Karp In-Reply-To: <1772997314.36411214315756575.JavaMail.root@dogfood.zimbra.com> References: <1772997314.36411214315756575.JavaMail.root@dogfood.zimbra.com> Date: Tue, 24 Jun 2008 19:19:31 +0200 Message-Id: <1214327971.13208.4.camel@nerts> Mime-Version: 1.0 X-Mailer: Evolution 2.22.2 Cc: Enhancements to Internet email to support diverse service enivronments Subject: Re: [lemonade] Why we should let the IMAP specification become more rich, rather than poor X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org On Tue, 2008-06-24 at 06:55 -0700, Dan Karp wrote: > > Would it make sense to claim in the RFC that you MUST NOT call > > yourself an IMAP server if you advertise capabilities that are > > not publicized as either RFC or in proposal at IETF? > > Nope. RFC 3501 is pretty clear that servers can advertise any > X-capabilities that they want; only ones that don't start with > "X" are constrained in the way you desire: > > Capability names MUST either begin with "X" or be standard or > standards-track IMAP4rev1 extensions, revisions, or amendments > registered with IANA. A server MUST NOT offer unregistered or > non-standard capability names, unless such names are prefixed with > an "X". Aha, that indeed justifies a capability name like XYZZY. I rest my case. -- Philip Van Hoof, freelance software developer home: me at pvanhoof dot be gnome: pvanhoof at gnome dot org http://pvanhoof.be/blog http://codeminded.be _______________________________________________ lemonade mailing list lemonade@ietf.org https://www.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Wed Jun 25 01:17:38 2008 Return-Path: X-Original-To: lemonade-archive@optimus.ietf.org Delivered-To: ietfarch-lemonade-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E76A93A6834; Wed, 25 Jun 2008 01:17:38 -0700 (PDT) X-Original-To: lemonade@core3.amsl.com Delivered-To: lemonade@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 607F23A6834 for ; Wed, 25 Jun 2008 01:17:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E4qAFDY0JWNz for ; Wed, 25 Jun 2008 01:17:36 -0700 (PDT) Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id 03F1E3A680B for ; Wed, 25 Jun 2008 01:17:35 -0700 (PDT) Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-mx03.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m5P8HOhQ007563; Wed, 25 Jun 2008 11:17:34 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by vaebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 25 Jun 2008 11:17:33 +0300 Received: from esebe199.NOE.Nokia.com ([172.21.138.143]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 25 Jun 2008 11:17:33 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 25 Jun 2008 11:17:32 +0300 Message-ID: <1ABB15342B0BE840B06B7D90A127AFD2371E38@esebe199.NOE.Nokia.com> In-Reply-To: <1214327971.13208.4.camel@nerts> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [lemonade] Why we should let the IMAP specification become morerich, rather than poor Thread-Index: AcjWHn6yP9nj6/FYR2G3mstTmedAeAAfRmXA References: <1772997314.36411214315756575.JavaMail.root@dogfood.zimbra.com> <1214327971.13208.4.camel@nerts> From: To: , X-OriginalArrivalTime: 25 Jun 2008 08:17:33.0261 (UTC) FILETIME=[EB18DFD0:01C8D69B] X-Nokia-AV: Clean Cc: lemonade@ietf.org Subject: Re: [lemonade] Why we should let the IMAP specification become morerich, rather than poor X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org Hi all, IMHO, supporting dozens of proprietary (X) extensions does not make a serve= r IMAP or Lemonade compliant. Proper implementation of standards track RFCs does. Best regards: Zolt=E1n =D6rd=F6gh E-mail: zoltan dot ordogh at nokia dot com Phone: +358 50 386 0566 -----Original Message----- From: lemonade-bounces@ietf.org [mailto:lemonade-bounces@ietf.org] On Behal= f Of ext Philip Van Hoof Sent: 24 June, 2008 20:20 To: Dan Karp Cc: Enhancements to Internet email to support diverse service enivronments Subject: Re: [lemonade] Why we should let the IMAP specification become mor= erich, rather than poor On Tue, 2008-06-24 at 06:55 -0700, Dan Karp wrote: > > Would it make sense to claim in the RFC that you MUST NOT call = > > yourself an IMAP server if you advertise capabilities that are not = > > publicized as either RFC or in proposal at IETF? > = > Nope. RFC 3501 is pretty clear that servers can advertise any = > X-capabilities that they want; only ones that don't start with "X" are = > constrained in the way you desire: > = > Capability names MUST either begin with "X" or be standard or > standards-track IMAP4rev1 extensions, revisions, or amendments > registered with IANA. A server MUST NOT offer unregistered or > non-standard capability names, unless such names are prefixed with > an "X". Aha, that indeed justifies a capability name like XYZZY. I rest my case. -- Philip Van Hoof, freelance software developer home: me at pvanhoof dot be gnome: pvanhoof at gnome dot org http://pvanhoof.be/blog http://codeminded.be _______________________________________________ lemonade mailing list lemonade@ietf.org https://www.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade _______________________________________________ lemonade mailing list lemonade@ietf.org https://www.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Thu Jun 26 10:30:06 2008 Return-Path: X-Original-To: lemonade-archive@optimus.ietf.org Delivered-To: ietfarch-lemonade-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EDD283A6B15; Thu, 26 Jun 2008 10:30:06 -0700 (PDT) X-Original-To: lemonade@ietf.org Delivered-To: lemonade@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 81A2A3A6A40; Thu, 26 Jun 2008 10:30:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20080626173001.81A2A3A6A40@core3.amsl.com> Date: Thu, 26 Jun 2008 10:30:01 -0700 (PDT) Cc: lemonade@ietf.org Subject: [lemonade] I-D ACTION:draft-ietf-lemonade-imap-notify-06.txt X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: lemonade-bounces@ietf.org 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 : The IMAP NOTIFY Extension Author(s) : C. King Filename : draft-ietf-lemonade-imap-notify-06.txt Pages : 22 Date : 2008-6-26 This document defines an IMAP extension which allows a client to request specific kinds of unsolicited notifications for specified mailboxes, such as messages being added to or deleted from mailboxes. [[Add Updates: RFC-CONTEXT to the headers]] A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-lemonade-imap-notify-06.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ 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: Message/External-body; name="draft-ietf-lemonade-imap-notify-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-6-26102523.I-D@ietf.org> --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://www.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade --NextPart-- From lemonade-bounces@ietf.org Thu Jun 26 11:18:15 2008 Return-Path: X-Original-To: lemonade-archive@optimus.ietf.org Delivered-To: ietfarch-lemonade-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 31E0A3A6933; Thu, 26 Jun 2008 11:18:15 -0700 (PDT) X-Original-To: lemonade@core3.amsl.com Delivered-To: lemonade@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C63793A6933 for ; Thu, 26 Jun 2008 11:18:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.436 X-Spam-Level: X-Spam-Status: No, score=-6.436 tagged_above=-999 required=5 tests=[AWL=0.163, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id szcNlZXlbaxG for ; Thu, 26 Jun 2008 11:18:14 -0700 (PDT) Received: from dovecot.org (dovecot.org [82.118.211.50]) by core3.amsl.com (Postfix) with ESMTP id CFF0F3A6802 for ; Thu, 26 Jun 2008 11:18:13 -0700 (PDT) Received: from [192.168.10.200] (xdsl-177-118.nblnetworks.fi [217.30.177.118]) by dovecot.org (Postfix) with ESMTP id 0E66916471E8 for ; Thu, 26 Jun 2008 21:17:43 +0300 (EEST) Message-Id: From: Timo Sirainen To: Lemonade WG In-Reply-To: <20080626173001.81A2A3A6A40@core3.amsl.com> Mime-Version: 1.0 (Apple Message framework v924) Date: Thu, 26 Jun 2008 21:17:38 +0300 References: <20080626173001.81A2A3A6A40@core3.amsl.com> X-Pgp-Agent: GPGMail d51 (Leopard) X-Mailer: Apple Mail (2.924) Subject: Re: [lemonade] I-D ACTION:draft-ietf-lemonade-imap-notify-06.txt X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1648926017==" Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============1648926017== Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-1--26142582" Content-Transfer-Encoding: 7bit This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-1--26142582 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit > < UNSEEN?>> My suggestion would be MessageNew-like parameters, maybe: - FlagChange : Track all changes, don't return UNSEEN - FlagChange (\Seen \*) : Track all changes, return UNSEEN - FlagChange (\Seen) : Track only \Seen changes, return UNSEEN This would also allow in future: - FlagChange ($keyword1 $keyword2) 2) Perhaps the ABNF should be changed so that filter-mailboxes- selected can only contain message-events? And related to that: Is the NONE events useful elsewhere than for SELECTED/SELECTED-DELAYED? I don't think so? So maybe the ABNF could be like: event-group = event-group-selected / event-group-other event-group-selected = "(" filter-mailboxes-selected SP message-events ")" message-events = ( "(" message-event *(SP message-event) ")" ) / "NONE" events = ( "(" event *(SP event) ")" ) ;; NONE dropped --Apple-Mail-1--26142582 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig content-transfer-encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) iEYEARECAAYFAkhj3UIACgkQyUhSUUBVislvBwCgmttsVShiGSTwI15Q6Cfj4o3n qB4An3kf0YMk9pPLxQhB+boxop7Fg8I2 =ZoKC -----END PGP SIGNATURE----- --Apple-Mail-1--26142582-- --===============1648926017== 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://www.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade --===============1648926017==--