From mrc+ietf@panda.com Tue Aug 2 09:31:33 2011 Return-Path: X-Original-To: imap5@ietfa.amsl.com Delivered-To: imap5@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A718F21F85A4 for ; Tue, 2 Aug 2011 09:31:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.538 X-Spam-Level: X-Spam-Status: No, score=-2.538 tagged_above=-999 required=5 tests=[AWL=0.061, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WZ+Y0RiTXojo for ; Tue, 2 Aug 2011 09:31:33 -0700 (PDT) Received: from Panda.COM (panda.com [206.124.149.114]) by ietfa.amsl.com (Postfix) with ESMTP id 95E5C21F853E for ; Tue, 2 Aug 2011 09:31:30 -0700 (PDT) Received: from hsinghsing.panda.com ([206.124.149.116]) by Panda.COM ([192.107.14.50]) with ESMTP via TCP; Tue, 02 Aug 2011 09:31:30 -0700 X-MailFrom: mrc+ietf@panda.com Date: Tue, 2 Aug 2011 09:31:29 -0700 (PDT) From: Mark Crispin Sender: mrc@hsinghsing.panda.com To: imap5@ietf.org Message-ID: User-Agent: Alpine 2.00 (OSX 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Subject: [imap5] something to remember in light of recent conversations X-BeenThere: imap5@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion on drastically slimming-down IMAP." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Aug 2011 16:31:33 -0000 http://www.xkcd.com/927/ -- Mark -- http://panda.com/mrc Democracy is two wolves and a sheep deciding what to eat for lunch. Liberty is a well-armed sheep contesting the vote. From brong@fastmail.fm Tue Aug 2 11:50:24 2011 Return-Path: X-Original-To: imap5@ietfa.amsl.com Delivered-To: imap5@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6A6121F8610 for ; Tue, 2 Aug 2011 11:50:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_47=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QfGlQvp-Q8R2 for ; Tue, 2 Aug 2011 11:50:24 -0700 (PDT) Received: from out2.smtp.messagingengine.com (out2.smtp.messagingengine.com [66.111.4.26]) by ietfa.amsl.com (Postfix) with ESMTP id D3EA221F873A for ; Tue, 2 Aug 2011 11:50:23 -0700 (PDT) Received: from compute4.internal (compute4.nyi.mail.srv.osa [10.202.2.44]) by gateway1.messagingengine.com (Postfix) with ESMTP id EA8A820801; Tue, 2 Aug 2011 14:50:32 -0400 (EDT) Received: from frontend2.messagingengine.com ([10.202.2.161]) by compute4.internal (MEProxy); Tue, 02 Aug 2011 14:50:32 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=date:from:to:cc:subject:message-id :references:mime-version:content-type:in-reply-to; s=smtpout; bh=kSTcZ8nBAYxmhle1vHoyFBhMIhU=; b=ohP35+psMoGJkzaxolUXC8+1A9MG AxSzVezg03xyZCqERPZa6NEpNyisQA8GWiLqvhLm4rgVKEeWwK7Iky0JRoy7V5rn jppS2HGiqfR4ZSX4FsN7JjSRLMdI1Rcuqjn+3wO/xVZ2cqMM7dkzUkbwHf95HPKM urbBdPufXbBmciA= X-Sasl-enc: 6nY8De2OUnpdafx7MHdgo+2P+j4LaiK5iZMT0oIPH9Uf 1312311032 Received: from localhost (56.243.9.46.customer.cdi.no [46.9.243.56]) by mail.messagingengine.com (Postfix) with ESMTPSA id AE951452911; Tue, 2 Aug 2011 14:50:32 -0400 (EDT) Received: by localhost (Postfix, from userid 1000) id A61FF20295; Tue, 2 Aug 2011 20:50:31 +0200 (CEST) Date: Tue, 2 Aug 2011 20:50:31 +0200 From: Bron Gondwana To: Mark Crispin Message-ID: <20110802185031.GA13692@brong.net> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Organization: brong.net User-Agent: Mutt/1.5.21 (2010-09-15) Cc: imap5@ietf.org Subject: Re: [imap5] something to remember in light of recent conversations X-BeenThere: imap5@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion on drastically slimming-down IMAP." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Aug 2011 18:50:24 -0000 On Tue, Aug 02, 2011 at 09:31:29AM -0700, Mark Crispin wrote: > http://www.xkcd.com/927/ I'll see you and raise you: http://www.dilbert.com/strips/comic/2011-08-02/ More seriously, I do concede that an IMAP "submit" command is purely a re-invention of something that's covered by existing methods, but I do believe it can provide a better client experience. Of course this is the one of my 4 suggestions for improvements to IMAP that got all the attention. But - there's no rational alternative to GUID, DIGEST or MOVE out there. MOVE is emulated with COPY+EXPUNGE, but this have the disadvantage of hitting quota limits. We see that frequently, largely because of: "delete is Move to Trash". But that's what users want and expect, so telling me "it's wrong to use that workflow" is not convincing. GUID can be mostly emulated with Message-Id, but the reality is that it's only somewhat-unique among messages in the wild, which isn't good enough for anything but a heuristic, and DIGEST is only emulatable by either a hueristic again, or downloading the whole message. It's interesting to see that gmail created a GUID equivalent in their extended API, because it's something they use internally. It maps nicely to POP too. Bron. From dave@cridland.net Tue Aug 2 13:17:36 2011 Return-Path: X-Original-To: imap5@ietfa.amsl.com Delivered-To: imap5@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E689F21F84DC for ; Tue, 2 Aug 2011 13:17:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.231 X-Spam-Level: X-Spam-Status: No, score=-2.231 tagged_above=-999 required=5 tests=[AWL=-0.232, BAYES_00=-2.599, J_CHICKENPOX_47=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ERPY1jzouijq for ; Tue, 2 Aug 2011 13:17:36 -0700 (PDT) Received: from peirce.dave.cridland.net (peirce.dave.cridland.net [IPv6:2001:470:1f09:882:2e0:81ff:fe29:d16a]) by ietfa.amsl.com (Postfix) with ESMTP id 3759A21F84D3 for ; Tue, 2 Aug 2011 13:17:36 -0700 (PDT) Received: from localhost (peirce.dave.cridland.net [127.0.0.1]) by peirce.dave.cridland.net (Postfix) with ESMTP id C81981168087; Tue, 2 Aug 2011 21:17:38 +0100 (BST) X-Virus-Scanned: Debian amavisd-new at peirce.dave.cridland.net Received: from peirce.dave.cridland.net ([127.0.0.1]) by localhost (peirce.dave.cridland.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2lNBlT9iVx8y; Tue, 2 Aug 2011 21:17:36 +0100 (BST) Received: from puncture (puncture.dave.cridland.net [IPv6:2001:470:1f09:882:221:85ff:fe3f:1696]) by peirce.dave.cridland.net (Postfix) with ESMTPA id 231501168067; Tue, 2 Aug 2011 21:17:36 +0100 (BST) References: <20110802185031.GA13692@brong.net> In-Reply-To: <20110802185031.GA13692@brong.net> MIME-Version: 1.0 Message-Id: <9031.1312316256.119145@puncture> Date: Tue, 02 Aug 2011 21:17:36 +0100 From: Dave Cridland To: Bron Gondwana , "Discussion on drastically slimming-down IMAP\." , Mark Crispin Content-Type: text/plain; delsp="yes"; charset="us-ascii"; format="flowed" Subject: Re: [imap5] something to remember in light of recent conversations X-BeenThere: imap5@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion on drastically slimming-down IMAP." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Aug 2011 20:17:37 -0000 On Tue Aug 2 19:50:31 2011, Bron Gondwana wrote: > More seriously, I do concede that an IMAP "submit" command is purely > a re-invention of something that's covered by existing methods, but > I > do believe it can provide a better client experience. Of course > this > is the one of my 4 suggestions for improvements to IMAP that got all > the attention. > > I'm not convinced the gain is worth the effort. > But - there's no rational alternative to GUID, DIGEST or MOVE out > there. > MOVE is emulated with COPY+EXPUNGE, but this have the disadvantage > of > hitting quota limits. We see that frequently, largely because of: > "delete is Move to Trash". But that's what users want and expect, > so telling me "it's wrong to use that workflow" is not convincing. > > A Trash command, possibly with associated \Deleted magic, might be the better solution here. We have gone through a substantial dance around MOVE recently, I did become convinced that some form of MOVE might actually work, if one limited one's expectations sufficiently. But I suspect that for the specific case of "deleting messages", a specific command might be warranted. The problem I have with move-as-delete is basically that it's not the metaphor that the system is designed for; it's the moral equivalent of deleting files on a UNIX system solely by "mv". Except it's worse, because if you did that, you could at least move them back to the same place. That said, I do see the value of being able to locate all one's deleted messages. > GUID can be mostly emulated with Message-Id, but the reality is > that it's > only somewhat-unique among messages in the wild, which isn't good > enough > for anything but a heuristic, and DIGEST is only emulatable by > either a > hueristic again, or downloading the whole message. > > It's interesting to see that gmail created a GUID equivalent in > their > extended API, because it's something they use internally. It maps > nicely to POP too. GUID and/or a DIGEST - and I think there's a large overlap there - should be just a matter of writing the spec out. I don't think anyone's violently against those, are they? 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 From brong@fastmail.fm Tue Aug 2 13:39:06 2011 Return-Path: X-Original-To: imap5@ietfa.amsl.com Delivered-To: imap5@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E1CB11E807F for ; Tue, 2 Aug 2011 13:39:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.269 X-Spam-Level: X-Spam-Status: No, score=-3.269 tagged_above=-999 required=5 tests=[AWL=-0.270, BAYES_00=-2.599, J_CHICKENPOX_47=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s4Ghi47ojN+8 for ; Tue, 2 Aug 2011 13:39:05 -0700 (PDT) Received: from out2.smtp.messagingengine.com (out2.smtp.messagingengine.com [66.111.4.26]) by ietfa.amsl.com (Postfix) with ESMTP id 60DE111E8082 for ; Tue, 2 Aug 2011 13:39:05 -0700 (PDT) Received: from compute6.internal (compute6.nyi.mail.srv.osa [10.202.2.46]) by gateway1.messagingengine.com (Postfix) with ESMTP id 49BFC2032E; Tue, 2 Aug 2011 16:39:15 -0400 (EDT) Received: from frontend2.messagingengine.com ([10.202.2.161]) by compute6.internal (MEProxy); Tue, 02 Aug 2011 16:39:15 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=date:from:to:cc:subject:message-id :references:mime-version:content-type:in-reply-to; s=smtpout; bh=DV51IzgmaF5xhq14IUwbd8r/ghg=; b=R47FR0a1OffHUzmWsUv2O0NYW8yR luRVy0V+IY86RbAPpW/+gvO+Wq4mUWFEji/waXYfm0ptnYrWJDDpU8NzHoP/opMA VL5/n0MWdiRwYGI7izOECmx0hj9+/H/wlPwV4W2BGM2gYSyi2iYpJjs24NCs9akK U1KM9qrz1EztkKI= X-Sasl-enc: a2h1oiQIG/MH6oA52Du8NT4oFDhELk1kCSTpS3XTFjRa 1312317554 Received: from localhost (56.243.9.46.customer.cdi.no [46.9.243.56]) by mail.messagingengine.com (Postfix) with ESMTPSA id DD44E456FC1; Tue, 2 Aug 2011 16:39:14 -0400 (EDT) Received: by localhost (Postfix, from userid 1000) id A8C1820295; Tue, 2 Aug 2011 22:39:13 +0200 (CEST) Date: Tue, 2 Aug 2011 22:39:13 +0200 From: Bron Gondwana To: Dave Cridland Message-ID: <20110802203913.GA15456@brong.net> References: <20110802185031.GA13692@brong.net> <9031.1312316256.119145@puncture> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9031.1312316256.119145@puncture> Organization: brong.net User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "Discussion on drastically slimming-down IMAP." Subject: Re: [imap5] something to remember in light of recent conversations X-BeenThere: imap5@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion on drastically slimming-down IMAP." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Aug 2011 20:39:06 -0000 On Tue, Aug 02, 2011 at 09:17:36PM +0100, Dave Cridland wrote: > On Tue Aug 2 19:50:31 2011, Bron Gondwana wrote: > >More seriously, I do concede that an IMAP "submit" command is purely > >a re-invention of something that's covered by existing methods, > >but I > >do believe it can provide a better client experience. Of course > >this > >is the one of my 4 suggestions for improvements to IMAP that got all > >the attention. > > > > > I'm not convinced the gain is worth the effort. I'm only partially convinced. I'm going to have a look at it again when I get some development time to spend on it. > >But - there's no rational alternative to GUID, DIGEST or MOVE out > >there. > >MOVE is emulated with COPY+EXPUNGE, but this have the disadvantage > >of > >hitting quota limits. We see that frequently, largely because of: > >"delete is Move to Trash". But that's what users want and expect, > >so telling me "it's wrong to use that workflow" is not convincing. > > > > > A Trash command, possibly with associated \Deleted magic, might be > the better solution here. Hmm... perhaps. Along with SPECIAL-USE so that the Trash folder is findable easily. Then again, it doesn't solve the issue of archiving half your INBOX off to an Archive folder when you're close to quota. Copying messages one at a time kinda sucks as a workaround. > We have gone through a substantial dance around MOVE recently, I did > become convinced that some form of MOVE might actually work, if one > limited one's expectations sufficiently. I'm fairly happy to limit expectations to "it works just like COPY+STORE+EXPUNGE in that order, except it doesn't fail if the folders are inside the same quotaroot and an intermediate state would have bumped the quota. It also doesn't cause overquota rejection of delivered messages during the action". > But I suspect that for the specific case of "deleting messages", a > specific command might be warranted. The general case of moving messages between folders is still a problem. We get support requests for both. > The problem I have with move-as-delete is basically that it's not > the metaphor that the system is designed for; it's the moral > equivalent of deleting files on a UNIX system solely by "mv". Except > it's worse, because if you did that, you could at least move them > back to the same place. Sorry, how can't you move messages back to where they were deleted from when they're in Trash? It's the same metaphor that is used on Windows, on Mac, and on modern "desktop environments"[tm] on Linux. It's a very familiar paradigm. Also, we store a "source folder" flag on every message that's copied to Trash through our new web interface so that we can implement an "undo" for deletes. It's a skanky Base-64 encoded value or something. We may replace it with an annotation now we have real per-message annotation support. > That said, I do see the value of being able to locate all one's > deleted messages. It's more that leaving them in the folder is unsafe with random clients, far too many call CLOSE or EXPUNGE and wipe out the deleted messages they didn't create themselves. > GUID and/or a DIGEST - and I think there's a large overlap there - > should be just a matter of writing the spec out. I don't think > anyone's violently against those, are they? I hope not :) There's kind of a devil in the details with DIGEST, if you start offering arbitrary algorithms on arbitrary parts or ranges of parts - and how do you tell clients which ones you're caching and hence are "fast". GUID is somewhat more simple. I should get my writing hat on. I haven't looked at the process for proposing and getting standards accepted - far easier to flame on mailing lists. I should fix myself and do something about that! Bron. From mrc+ietf@panda.com Tue Aug 2 13:47:19 2011 Return-Path: X-Original-To: imap5@ietfa.amsl.com Delivered-To: imap5@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97FB511E8098 for ; Tue, 2 Aug 2011 13:47:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.544 X-Spam-Level: X-Spam-Status: No, score=-2.544 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aJi6usxnSnMX for ; Tue, 2 Aug 2011 13:47:19 -0700 (PDT) Received: from Panda.COM (panda.com [206.124.149.114]) by ietfa.amsl.com (Postfix) with ESMTP id C732511E808F for ; Tue, 2 Aug 2011 13:47:18 -0700 (PDT) Received: from hsinghsing.panda.com ([206.124.149.116]) by Panda.COM ([192.107.14.50]) with ESMTP via TCP; Tue, 02 Aug 2011 13:47:19 -0700 X-MailFrom: mrc+ietf@panda.com Date: Tue, 2 Aug 2011 13:47:17 -0700 (PDT) From: Mark Crispin Sender: mrc@hsinghsing.panda.com To: Bron Gondwana In-Reply-To: <20110802203913.GA15456@brong.net> Message-ID: References: <20110802185031.GA13692@brong.net> <9031.1312316256.119145@puncture> <20110802203913.GA15456@brong.net> User-Agent: Alpine 2.00 (OSX 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: "Discussion on drastically slimming-down IMAP." Subject: Re: [imap5] something to remember in light of recent conversations X-BeenThere: imap5@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion on drastically slimming-down IMAP." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Aug 2011 20:47:19 -0000 On Tue, 2 Aug 2011, Bron Gondwana wrote: > Sorry, how can't you move messages back to where they were deleted > from when they're in Trash? Review the UID assignment rules. Once a UID is expunged from a mailbox, it can't be reused. That means that a message can not reappear with the same UID that it had before. You can only make a new instance of the message with a new UID. The whole notion of moving messages to a Trash mailbox is fundamentally flawed. It confuses a user interface paradigm with an internal representation. -- Mark -- http://panda.com/mrc Democracy is two wolves and a sheep deciding what to eat for lunch. Liberty is a well-armed sheep contesting the vote. From brong@fastmail.fm Tue Aug 2 14:00:55 2011 Return-Path: X-Original-To: imap5@ietfa.amsl.com Delivered-To: imap5@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9388821F8777 for ; Tue, 2 Aug 2011 14:00:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.544 X-Spam-Level: X-Spam-Status: No, score=-3.544 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0bM6M76B+r-b for ; Tue, 2 Aug 2011 14:00:54 -0700 (PDT) Received: from out2.smtp.messagingengine.com (out2.smtp.messagingengine.com [66.111.4.26]) by ietfa.amsl.com (Postfix) with ESMTP id B082221F8760 for ; Tue, 2 Aug 2011 14:00:54 -0700 (PDT) Received: from compute4.internal (compute4.nyi.mail.srv.osa [10.202.2.44]) by gateway1.messagingengine.com (Postfix) with ESMTP id 61E1A20AC9; Tue, 2 Aug 2011 17:01:02 -0400 (EDT) Received: from frontend2.messagingengine.com ([10.202.2.161]) by compute4.internal (MEProxy); Tue, 02 Aug 2011 17:01:02 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=date:from:to:cc:subject:message-id :references:mime-version:content-type:in-reply-to; s=smtpout; bh=sGwi20mEMCQDz4L35rxHn6J66Zo=; b=Kd7p8iHX7K+WpPPwJHsqAY3snXKt FbVas9v9Kq+K0L0b0QxpLMu9dRHv9t4dSWc2GBCCm+B9rd8gCDEQFjb+ejrtU1Ng PAppEh3Z2fGRGRo8Y4NbDOZ0pLbleOcMm+h2yTTmnaZ7JE4Oq6VwQaHcq8/oAv6+ /3ReF1CQlJebsZU= X-Sasl-enc: 4PfDn1tuKsHxgMR+qM4eFqxJm0Wb3uO1MGbfEhsf8f1t 1312318862 Received: from localhost (56.243.9.46.customer.cdi.no [46.9.243.56]) by mail.messagingengine.com (Postfix) with ESMTPSA id 1B228457A8C; Tue, 2 Aug 2011 17:01:02 -0400 (EDT) Received: by localhost (Postfix, from userid 1000) id 06F9520295; Tue, 2 Aug 2011 23:01:01 +0200 (CEST) Date: Tue, 2 Aug 2011 23:01:01 +0200 From: Bron Gondwana To: Mark Crispin Message-ID: <20110802210101.GA16087@brong.net> References: <20110802185031.GA13692@brong.net> <9031.1312316256.119145@puncture> <20110802203913.GA15456@brong.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Organization: brong.net User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "Discussion on drastically slimming-down IMAP." Subject: Re: [imap5] something to remember in light of recent conversations X-BeenThere: imap5@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion on drastically slimming-down IMAP." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Aug 2011 21:00:55 -0000 On Tue, Aug 02, 2011 at 01:47:17PM -0700, Mark Crispin wrote: > On Tue, 2 Aug 2011, Bron Gondwana wrote: > >Sorry, how can't you move messages back to where they were deleted > >from when they're in Trash? > > Review the UID assignment rules. > > Once a UID is expunged from a mailbox, it can't be reused. That means > that a message can not reappear with the same UID that it had before. No shit - you append it with a new UID. Despite your repeated attempts to paint me as one, I'm not a blithering moron. > You can only make a new instance of the message with a new UID. Indeed. Though if you have a GUID or DIGEST you can fairly efficiently detect this case - and along with the case of an accidental move and move back, which has the same underlying issue. > The whole notion of moving messages to a Trash mailbox is fundamentally > flawed. It confuses a user interface paradigm with an internal > representation. I don't even know how to start responding to this. The user interface paradigm needs an internal representation. There is a user interface that people have clearly chosen, for whatever reason - wrongheaded or not - take your pick. My interest is in coming up with an internal representation that actually provides the interface users want rather than telling them to alter themselves to make my life easier. I believe in having the computer do extra work so that users don't have to. You appear to believe the opposite, that users should change their behaviour to make life easier for the computer. I can't cross this divide and join you I'm afraid. Bron. From dave@cridland.net Tue Aug 2 14:02:17 2011 Return-Path: X-Original-To: imap5@ietfa.amsl.com Delivered-To: imap5@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9ACC021F877B for ; Tue, 2 Aug 2011 14:02:17 -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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7OqizoJKbLz2 for ; Tue, 2 Aug 2011 14:02:16 -0700 (PDT) Received: from peirce.dave.cridland.net (peirce.dave.cridland.net [IPv6:2001:470:1f09:882:2e0:81ff:fe29:d16a]) by ietfa.amsl.com (Postfix) with ESMTP id 19C3621F8757 for ; Tue, 2 Aug 2011 14:02:16 -0700 (PDT) Received: from localhost (peirce.dave.cridland.net [127.0.0.1]) by peirce.dave.cridland.net (Postfix) with ESMTP id 102E31168087; Tue, 2 Aug 2011 22:02:24 +0100 (BST) X-Virus-Scanned: Debian amavisd-new at peirce.dave.cridland.net Received: from peirce.dave.cridland.net ([127.0.0.1]) by localhost (peirce.dave.cridland.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1SN5IiwYNYjH; Tue, 2 Aug 2011 22:02:19 +0100 (BST) Received: from puncture (puncture.dave.cridland.net [IPv6:2001:470:1f09:882:221:85ff:fe3f:1696]) by peirce.dave.cridland.net (Postfix) with ESMTPA id 5B04D1168067; Tue, 2 Aug 2011 22:02:19 +0100 (BST) References: <20110802185031.GA13692@brong.net> <9031.1312316256.119145@puncture> <20110802203913.GA15456@brong.net> In-Reply-To: <20110802203913.GA15456@brong.net> MIME-Version: 1.0 Message-Id: <9031.1312318939.365875@puncture> Date: Tue, 02 Aug 2011 22:02:19 +0100 From: Dave Cridland To: Bron Gondwana , "Discussion on drastically slimming-down IMAP\." , Mark Crispin Content-Type: text/plain; delsp="yes"; charset="us-ascii"; format="flowed" Subject: Re: [imap5] something to remember in light of recent conversations X-BeenThere: imap5@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion on drastically slimming-down IMAP." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Aug 2011 21:02:17 -0000 On Tue Aug 2 21:39:13 2011, Bron Gondwana wrote: > Hmm... perhaps. Along with SPECIAL-USE so that the Trash folder is > findable easily. Then again, it doesn't solve the issue of > archiving half your INBOX off to an Archive folder when you're > close to quota. Copying messages one at a time kinda sucks as a > workaround. Except I'm *very* far from convinced that archival of messages is a suitable reaction to getting close to quota. > I'm fairly happy to limit expectations to "it works just like > COPY+STORE+EXPUNGE in that order, except it doesn't fail if the > folders are inside the same quotaroot and an intermediate state > would have bumped the quota. It also doesn't cause overquota > rejection of delivered messages during the action". RIght, but if you're close to quota, this is exactly the case where moving messages about isn't going to help much anyway. > > But I suspect that for the specific case of "deleting messages", a > > specific command might be warranted. > > The general case of moving messages between folders is still a > problem. > We get support requests for both. > > OK. Review the last thread on MOVE. There was a real concerted effort to finding a MOVE that would be maximlally implementable. It wasn't great, but it seemed better than no MOVE at all for a number of use cases. (It was, as I recall, roughly a one-at-a-time-but-serverside). > > The problem I have with move-as-delete is basically that it's not > > the metaphor that the system is designed for; it's the moral > > equivalent of deleting files on a UNIX system solely by "mv". > Except > > it's worse, because if you did that, you could at least move them > > back to the same place. > > Sorry, how can't you move messages back to where they were deleted > from when they're in Trash? It's the same metaphor that is used on > Windows, on Mac, and on modern "desktop environments"[tm] on Linux. > It's a very familiar paradigm. > > Two reasons: 1) You need to remember it, as you note: > Also, we store a "source folder" flag on every message that's copied > to Trash through our new web interface so that we can implement an > "undo" for deletes. It's a skanky Base-64 encoded value or > something. > We may replace it with an annotation now we have real per-message > annotation support. > > (Love the use of the word skanky, BTW) 2) The UID is messed up. This is particularly annoying if you don't have (or particularly want) SORT, and use of SORT really slows down online low-bandwidth use. The UID is basically the filename equivalent; so on UNIX you can pseudo-delete by "mv foo ~/Trash", and then undelete by "mv ~/Trash/foo .", whereas on IMAP you cannot. (And yes, I know that's not really how trash folders work in Linux; they have to preserver the original filename and deleted timestamp in order to handle multiple deletes etc). > > That said, I do see the value of being able to locate all one's > > deleted messages. > > It's more that leaving them in the folder is unsafe with random > clients, far too many call CLOSE or EXPUNGE and wipe out the > deleted messages they didn't create themselves. > > OK, so we'd need a flippy switch to turn off EXPUNGEs. Perhaps the server can be told that you use "trash aware" clients and needs an ENABLE before EXPUNGE works again, or something. I can forsee support problems, mind, but I think the flag-as-deleted model is also worth preserving if we can (I infinitely prefer it). It's worth noting that the \Deleted flag was state of the art for supporting undelete mechanisms of the time; the fact that fashion has changed is indeed significant, but I should stress that it was very far from an arbitrary decision. Also, doing it this way meant that costly mbox file rewriting could be done less, I suspect. > > GUID and/or a DIGEST - and I think there's a large overlap there - > > should be just a matter of writing the spec out. I don't think > > anyone's violently against those, are they? > > I hope not :) There's kind of a devil in the details with DIGEST, > if you start offering arbitrary algorithms on arbitrary parts or > ranges of parts - and how do you tell clients which ones you're > caching and hence are "fast". GUID is somewhat more simple. I was assuming DIGEST and GUID were largely identical, actually, but I can go along with this, I've honestly not thought about them much. > I should get my writing hat on. I haven't looked at the process for > proposing and getting standards accepted - far easier to flame on > mailing lists. I should fix myself and do something about that! http://tools.ietf.org/ has lots of pointers to help, including pointers to xml2rfc, a spell checker and nits checker, and a link to the submissions tool. It is generally easier to mount a constructive argument both for and against an I-D rather than a sketch in a mail message, so I'd encourage you to document even the ideas you know are likely to be shot down. 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 From dave@cridland.net Tue Aug 2 14:08:53 2011 Return-Path: X-Original-To: imap5@ietfa.amsl.com Delivered-To: imap5@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5F6111E80BC for ; Tue, 2 Aug 2011 14:08:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.526 X-Spam-Level: X-Spam-Status: No, score=-2.526 tagged_above=-999 required=5 tests=[AWL=0.073, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G1jzq9IoVq3l for ; Tue, 2 Aug 2011 14:08:53 -0700 (PDT) Received: from peirce.dave.cridland.net (peirce.dave.cridland.net [IPv6:2001:470:1f09:882:2e0:81ff:fe29:d16a]) by ietfa.amsl.com (Postfix) with ESMTP id B7E4E11E80B3 for ; Tue, 2 Aug 2011 14:08:52 -0700 (PDT) Received: from localhost (peirce.dave.cridland.net [127.0.0.1]) by peirce.dave.cridland.net (Postfix) with ESMTP id AF0561168087; Tue, 2 Aug 2011 22:09:01 +0100 (BST) X-Virus-Scanned: Debian amavisd-new at peirce.dave.cridland.net Received: from peirce.dave.cridland.net ([127.0.0.1]) by localhost (peirce.dave.cridland.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wOXUzREtAmed; Tue, 2 Aug 2011 22:08:59 +0100 (BST) Received: from puncture (puncture.dave.cridland.net [IPv6:2001:470:1f09:882:221:85ff:fe3f:1696]) by peirce.dave.cridland.net (Postfix) with ESMTPA id 696EE1168067; Tue, 2 Aug 2011 22:08:59 +0100 (BST) References: <20110802185031.GA13692@brong.net> <9031.1312316256.119145@puncture> <20110802203913.GA15456@brong.net> <20110802210101.GA16087@brong.net> In-Reply-To: <20110802210101.GA16087@brong.net> MIME-Version: 1.0 Message-Id: <9031.1312319339.425664@puncture> Date: Tue, 02 Aug 2011 22:08:59 +0100 From: Dave Cridland To: Bron Gondwana , "Discussion on drastically slimming-down IMAP\." , Mark Crispin Content-Type: text/plain; delsp="yes"; charset="us-ascii"; format="flowed" Subject: Re: [imap5] something to remember in light of recent conversations X-BeenThere: imap5@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion on drastically slimming-down IMAP." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Aug 2011 21:08:53 -0000 On Tue Aug 2 22:01:01 2011, Bron Gondwana wrote: > I don't even know how to start responding to this. The user > interface > paradigm needs an internal representation. There is a user > interface > that people have clearly chosen, for whatever reason - wrongheaded > or > not - take your pick. My interest is in coming up with an internal > representation that actually provides the interface users want > rather > than telling them to alter themselves to make my life easier. > > I believe in having the computer do extra work so that users don't > have to. You appear to believe the opposite, that users should > change > their behaviour to make life easier for the computer. I can't cross > this divide and join you I'm afraid. The question is which computer should be doing the work, and how much the UI paradigm needs to impose its model onto the exant model of the mailstore. I think there's a fair argument that "IMAP was there first", so the onus is somewhat on the mail client to handle the hard work, rather than passing the buck to the server. That said, I'm generally open to ways of supporting the model from the server, if possible and reasonable. This is basically why I'd be willing to look into (and work upon) a "Trash command" which could co-exist with a deleted-flag model. 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 From mrc+ietf@panda.com Tue Aug 2 14:13:16 2011 Return-Path: X-Original-To: imap5@ietfa.amsl.com Delivered-To: imap5@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 542A311E80A9 for ; Tue, 2 Aug 2011 14:13:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.548 X-Spam-Level: X-Spam-Status: No, score=-2.548 tagged_above=-999 required=5 tests=[AWL=0.051, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yjLzy5NA29dO for ; Tue, 2 Aug 2011 14:13:15 -0700 (PDT) Received: from Panda.COM (panda.com [206.124.149.114]) by ietfa.amsl.com (Postfix) with ESMTP id 7AE3911E808F for ; Tue, 2 Aug 2011 14:13:15 -0700 (PDT) Received: from hsinghsing.panda.com ([206.124.149.116]) by Panda.COM ([192.107.14.50]) with ESMTP via TCP; Tue, 02 Aug 2011 14:13:15 -0700 X-MailFrom: mrc+ietf@panda.com Date: Tue, 2 Aug 2011 14:13:14 -0700 (PDT) From: Mark Crispin Sender: mrc@hsinghsing.panda.com To: Bron Gondwana In-Reply-To: <20110802210101.GA16087@brong.net> Message-ID: References: <20110802185031.GA13692@brong.net> <9031.1312316256.119145@puncture> <20110802203913.GA15456@brong.net> <20110802210101.GA16087@brong.net> User-Agent: Alpine 2.00 (OSX 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Cc: "Discussion on drastically slimming-down IMAP." Subject: Re: [imap5] something to remember in light of recent conversations X-BeenThere: imap5@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion on drastically slimming-down IMAP." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Aug 2011 21:13:16 -0000 On Tue, 2 Aug 2011, Bron Gondwana wrote: > No shit - you append it with a new UID. Which is a completely new instance of the message, which every synchronizing client must redownload. > Despite your repeated attempts > to paint me as one, I'm not a blithering moron. Then stop acting like one. > I don't even know how to start responding to this. The user interface > paradigm needs an internal representation. No it does not. The user interface software maps from whatever internal representation is present to the paradigm that it presents to the user. > I believe in having the computer do extra work so that users don't > have to. If that is the case, then the computer software, not the protocols, should do the necessary work. It does not mean that protocols must be altered so that computer software is reduced to a null transform. > You appear to believe the opposite, that users should change > their behaviour to make life easier for the computer. I can't cross > this divide and join you I'm afraid. Maybe that is because you persist in making strawman arguments. -- Mark -- http://panda.com/mrc Democracy is two wolves and a sheep deciding what to eat for lunch. Liberty is a well-armed sheep contesting the vote. From brong@fastmail.fm Tue Aug 2 14:34:35 2011 Return-Path: X-Original-To: imap5@ietfa.amsl.com Delivered-To: imap5@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61E7E11E80A9 for ; Tue, 2 Aug 2011 14:34:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.549 X-Spam-Level: X-Spam-Status: No, score=-3.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aeHG75Rcn08x for ; Tue, 2 Aug 2011 14:34:34 -0700 (PDT) Received: from out2.smtp.messagingengine.com (out2.smtp.messagingengine.com [66.111.4.26]) by ietfa.amsl.com (Postfix) with ESMTP id 3198511E808F for ; Tue, 2 Aug 2011 14:34:34 -0700 (PDT) Received: from compute3.internal (compute3.nyi.mail.srv.osa [10.202.2.43]) by gateway1.messagingengine.com (Postfix) with ESMTP id F174020B46; Tue, 2 Aug 2011 17:34:43 -0400 (EDT) Received: from frontend2.messagingengine.com ([10.202.2.161]) by compute3.internal (MEProxy); Tue, 02 Aug 2011 17:34:43 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=date:from:to:cc:subject:message-id :references:mime-version:content-type:in-reply-to; s=smtpout; bh=YZiBvSS+9OcYqlrOdeMtM8LxZpk=; b=soI+Xb3fx1TVmWgGMeRDRL7+xNjK ezkkK/uAbSfW808+2YXn2q62qxxOYE4AxuVhAkQHU14DBV1qzXoPPPRF/x9OtcwX HKcYNwQQ4peBK7fuKGYCu/BZWdLei8rGRT0vJJeqJH/zDzJC4SbZlkmU0yPeBJjs 2fzl/ywWZaD9uEQ= X-Sasl-enc: 8ET8fCXiAlZj/sHIfLI1k0umo8Rj7wO/eTTK0C6Yu5hq 1312320883 Received: from localhost (56.243.9.46.customer.cdi.no [46.9.243.56]) by mail.messagingengine.com (Postfix) with ESMTPSA id 9246C457ACB; Tue, 2 Aug 2011 17:34:43 -0400 (EDT) Received: by localhost (Postfix, from userid 1000) id 7FC1B20295; Tue, 2 Aug 2011 23:34:42 +0200 (CEST) Date: Tue, 2 Aug 2011 23:34:42 +0200 From: Bron Gondwana To: Dave Cridland Message-ID: <20110802213442.GA16293@brong.net> References: <20110802185031.GA13692@brong.net> <9031.1312316256.119145@puncture> <20110802203913.GA15456@brong.net> <9031.1312318939.365875@puncture> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9031.1312318939.365875@puncture> Organization: brong.net User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "Discussion on drastically slimming-down IMAP." Subject: Re: [imap5] something to remember in light of recent conversations X-BeenThere: imap5@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion on drastically slimming-down IMAP." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Aug 2011 21:34:35 -0000 On Tue, Aug 02, 2011 at 10:02:19PM +0100, Dave Cridland wrote: > On Tue Aug 2 21:39:13 2011, Bron Gondwana wrote: > >Hmm... perhaps. Along with SPECIAL-USE so that the Trash folder is > >findable easily. Then again, it doesn't solve the issue of > >archiving half your INBOX off to an Archive folder when you're > >close to quota. Copying messages one at a time kinda sucks as a > >workaround. > > Except I'm *very* far from convinced that archival of messages is a > suitable reaction to getting close to quota. Oh no, it's not a reaction. It's just your normal monthly/yearly archiving, except you also happen to be close to quota. > >I'm fairly happy to limit expectations to "it works just like > >COPY+STORE+EXPUNGE in that order, except it doesn't fail if the > >folders are inside the same quotaroot and an intermediate state > >would have bumped the quota. It also doesn't cause overquota > >rejection of delivered messages during the action". > > RIght, but if you're close to quota, this is exactly the case where > moving messages about isn't going to help much anyway. You're not doing it to "help", you might be at 75% of quota and still months off being close to the limit, but want to move what amounts to 50% of your messages. If you move it all at once, you hit the quota, if you move it in little batches, you don't. Annoying and unintuative. > OK. Review the last thread on MOVE. There was a real concerted > effort to finding a MOVE that would be maximlally implementable. It > wasn't great, but it seemed better than no MOVE at all for a number > of use cases. (It was, as I recall, roughly a > one-at-a-time-but-serverside). The result being "can't fail in a way that leaves huge piles of steaming mess around if there's an error half way through" I'm guessing. It does have to minimally implementable at BOTH ends, of course, or it will wind up being minimally implemented, which is kind of pointless. > >Sorry, how can't you move messages back to where they were deleted > >from when they're in Trash? It's the same metaphor that is used on > >Windows, on Mac, and on modern "desktop environments"[tm] on Linux. > >It's a very familiar paradigm. > > Two reasons: > > 1) You need to remember it, as you note: Well, yeah. > 2) The UID is messed up. This is particularly annoying if you don't > have (or particularly want) SORT, and use of SORT really slows down > online low-bandwidth use. Again - yes, difficult. You could always be really obnoxious about it and just bump every message with a higher "original UID" up, but if someone accidentally deleted UID 1 and tried to undo you could eat up UIDs a bit fast. Of course, once you get close to 2^32 you just raise the UIDVALIDITY by one and renumber back from 1 again, so it's theoretically solvable. > The UID is basically the filename equivalent; so on UNIX you can > pseudo-delete by "mv foo ~/Trash", and then undelete by "mv > ~/Trash/foo .", whereas on IMAP you cannot. (And yes, I know that's > not really how trash folders work in Linux; they have to preserver > the original filename and deleted timestamp in order to handle > multiple deletes etc). Yeah, so there are some "impedence mismatches" between what's wanted and what IMAP provides. Many clients use SORT now of course, or cache everything locally so they can get the sorted-by-date view efficiently and render quickly. > >It's more that leaving them in the folder is unsafe with random > >clients, far too many call CLOSE or EXPUNGE and wipe out the > >deleted messages they didn't create themselves. > > OK, so we'd need a flippy switch to turn off EXPUNGEs. Perhaps the > server can be told that you use "trash aware" clients and needs an > ENABLE before EXPUNGE works again, or something. No dice. First non-aware client to connect and issue an EXPUNGE or CLOSE will wipe out your carefully assembled house-of-cards. The only way I can see it working is a 'non-expungable-but-\Deleted' flag. We did something like that in our web interface in the past when expunge was too expensive. We set 'medeleted' rather than the real deleted, and all "SORT"s were actually "SEARCH NOT FLAG medeleted". Talk about your workarounds. Layer a few of these together, and things get pretty horrible. Thankfully "EXPUNGE" in Cyrus now costs exactly as much as a FLAG store until the garbage collection happens, so clients aren't left implementing their own different workarounds for expensive server-side expunge. > I can forsee support problems, mind, but I think the flag-as-deleted > model is also worth preserving if we can (I infinitely prefer it). On what grounds? Mostly you see clients doing "UID STORE +FLAG \Deleted $uids" then "UID EXPUNGE $uids" if they're being polite - which is no different fundamentally than "UID DELETE $uids" other than pushing the intermediate state cleanup out to the clients. > It's worth noting that the \Deleted flag was state of the art for > supporting undelete mechanisms of the time; the fact that fashion > has changed is indeed significant, but I should stress that it was > very far from an arbitrary decision. Also, doing it this way meant > that costly mbox file rewriting could be done less, I suspect. Oh sure - it pushed the garbage collection out to the client. I can see why the decision was made, and like any tradeoff it has its good and bad points. I'm not arguing in any way that it's wrong. You certainly need a way for a client to be able to delete fast - indeed the client needs to be able to batch deletes if some punk is sitting there bouncing on the D key. I do that myself. And it's certainly easier on the server to put the responsibility for batching the mbox file rewrite on the client. Mind you, by the time you're supporting QRESYNC and CONDSTORE while still supporting RFC3501's requirement that sequence numbers don't change arbitrarily between batchable non-UID commands - you wind up having to support some sort of MVCC on the server anyway - at which point you wind up having to garbage collect enough state that regular EXPUNGE gets cheaper. > >I hope not :) There's kind of a devil in the details with DIGEST, > >if you start offering arbitrary algorithms on arbitrary parts or > >ranges of parts - and how do you tell clients which ones you're > >caching and hence are "fast". GUID is somewhat more simple. > > I was assuming DIGEST and GUID were largely identical, actually, but > I can go along with this, I've honestly not thought about them much. Google's GUID is a random string. http://code.google.com/apis/gmail/imap/#x-gm-msgid They also have a Thread ID which applies across folders X-GM-THRID. We have something very similar called 'CID' (conversations ID) but we're not providing to anything outside our testing environment yet. DIGEST on the other hand is something that can be calculated at the other end as well, so can be used for integrity checking of cached data, and detecting the same message even if it went out and back in via a copy between servers or from a client which moved them offline and forgot the fact, so APPENDed rather than COPY(i)ed. > >I should get my writing hat on. I haven't looked at the process for > >proposing and getting standards accepted - far easier to flame on > >mailing lists. I should fix myself and do something about that! > > http://tools.ietf.org/ has lots of pointers to help, including > pointers to xml2rfc, a spell checker and nits checker, and a link to > the submissions tool. Funky. Thanks. > It is generally easier to mount a constructive argument both for and > against an I-D rather than a sketch in a mail message, so I'd > encourage you to document even the ideas you know are likely to be > shot down. Will do. Thanks, Bron. From brong@fastmail.fm Tue Aug 2 14:37:24 2011 Return-Path: X-Original-To: imap5@ietfa.amsl.com Delivered-To: imap5@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE9B711E80C4 for ; Tue, 2 Aug 2011 14:37:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.553 X-Spam-Level: X-Spam-Status: No, score=-3.553 tagged_above=-999 required=5 tests=[AWL=0.046, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BiFoJx5kZlkj for ; Tue, 2 Aug 2011 14:37:24 -0700 (PDT) Received: from out2.smtp.messagingengine.com (out2.smtp.messagingengine.com [66.111.4.26]) by ietfa.amsl.com (Postfix) with ESMTP id E7F1211E808F for ; Tue, 2 Aug 2011 14:37:23 -0700 (PDT) Received: from compute3.internal (compute3.nyi.mail.srv.osa [10.202.2.43]) by gateway1.messagingengine.com (Postfix) with ESMTP id F1D6C20916; Tue, 2 Aug 2011 17:37:33 -0400 (EDT) Received: from frontend1.messagingengine.com ([10.202.2.160]) by compute3.internal (MEProxy); Tue, 02 Aug 2011 17:37:33 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=date:from:to:cc:subject:message-id :references:mime-version:content-type:in-reply-to; s=smtpout; bh=nM1/wpNXVKuVbsSBvlNg3sPnYsM=; b=aK99YadRdeQj9K1s3tnisfDG2Z9P ZDf3zLjHr3eLXmQAiQEAA8BKPJXLbyp+0EzF5mlNWI2sa1D0ClKUyWJ4ohLRuyxv Z9KyDekfvx7pyGuKa0GirK9CTd0gTBvXM6cj5pz9ztOxM4MfxzFohzOeWymOgwhu n6zEbFLm+47U9sw= X-Sasl-enc: YNZD+F48BRNdqOImdjHtvQrI+hDAERKSLMuv4DMkwQh3 1312321053 Received: from localhost (56.243.9.46.customer.cdi.no [46.9.243.56]) by mail.messagingengine.com (Postfix) with ESMTPSA id AF634416F0B; Tue, 2 Aug 2011 17:37:33 -0400 (EDT) Received: by localhost (Postfix, from userid 1000) id 6B4F620295; Tue, 2 Aug 2011 23:37:32 +0200 (CEST) Date: Tue, 2 Aug 2011 23:37:32 +0200 From: Bron Gondwana To: Dave Cridland Message-ID: <20110802213732.GB16293@brong.net> References: <20110802185031.GA13692@brong.net> <9031.1312316256.119145@puncture> <20110802203913.GA15456@brong.net> <20110802210101.GA16087@brong.net> <9031.1312319339.425664@puncture> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9031.1312319339.425664@puncture> Organization: brong.net User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "Discussion on drastically slimming-down IMAP." Subject: Re: [imap5] something to remember in light of recent conversations X-BeenThere: imap5@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion on drastically slimming-down IMAP." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Aug 2011 21:37:24 -0000 On Tue, Aug 02, 2011 at 10:08:59PM +0100, Dave Cridland wrote: > The question is which computer should be doing the work, and how > much the UI paradigm needs to impose its model onto the exant model > of the mailstore. > > I think there's a fair argument that "IMAP was there first", so the > onus is somewhat on the mail client to handle the hard work, rather > than passing the buck to the server. Absolutely. Except when the "impedence mismatch" (such a good term for describing the situation) gets too great, something has to give! Either clients migrate to a new protocol, or the existing protocol changes. > That said, I'm generally open to ways of supporting the model from > the server, if possible and reasonable. > > This is basically why I'd be willing to look into (and work upon) a > "Trash command" which could co-exist with a deleted-flag model. Excellent. Bron. From brong@fastmail.fm Tue Aug 2 15:19:52 2011 Return-Path: X-Original-To: imap5@ietfa.amsl.com Delivered-To: imap5@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FAB511E80CD for ; Tue, 2 Aug 2011 15:19:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.256 X-Spam-Level: X-Spam-Status: No, score=-3.256 tagged_above=-999 required=5 tests=[AWL=-0.257, BAYES_00=-2.599, J_CHICKENPOX_44=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G+VGoTIam2gH for ; Tue, 2 Aug 2011 15:19:51 -0700 (PDT) Received: from out2.smtp.messagingengine.com (out2.smtp.messagingengine.com [66.111.4.26]) by ietfa.amsl.com (Postfix) with ESMTP id 420D811E80A1 for ; Tue, 2 Aug 2011 15:19:51 -0700 (PDT) Received: from compute1.internal (compute1.nyi.mail.srv.osa [10.202.2.41]) by gateway1.messagingengine.com (Postfix) with ESMTP id 5244020AEC; Tue, 2 Aug 2011 18:20:01 -0400 (EDT) Received: from frontend2.messagingengine.com ([10.202.2.161]) by compute1.internal (MEProxy); Tue, 02 Aug 2011 18:20:01 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=date:from:to:cc:subject:message-id :references:mime-version:content-type:in-reply-to; s=smtpout; bh=oXvJE67BuMQKdKPQj19ah2GeHrg=; b=edyPEKaPxtZ0nwcofbhkYQ4K3vzB bfg6YHo5KJON4tkbGfQHI6zu0geLl6YgHYSVGAsXzzZ0ympXo1maSm1aeUKVek0f NxO92jXDhs+PcZHXiTMHKkmSvdOBNJsR1/LNQzHExbkPqAzyHlpgpAL8nXamNQXv xdBfj4BuCejHNEw= X-Sasl-enc: N1qI9rdPvMd9l06mqTGNBHuuucinGfWaTqTkUH42fC8w 1312323600 Received: from localhost (56.243.9.46.customer.cdi.no [46.9.243.56]) by mail.messagingengine.com (Postfix) with ESMTPSA id DE9394578AF; Tue, 2 Aug 2011 18:20:00 -0400 (EDT) Received: by localhost (Postfix, from userid 1000) id A86B1203C0; Wed, 3 Aug 2011 00:19:59 +0200 (CEST) Date: Wed, 3 Aug 2011 00:19:59 +0200 From: Bron Gondwana To: Mark Crispin Message-ID: <20110802221959.GA26605@brong.net> References: <20110802185031.GA13692@brong.net> <9031.1312316256.119145@puncture> <20110802203913.GA15456@brong.net> <20110802210101.GA16087@brong.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Organization: brong.net User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "Discussion on drastically slimming-down IMAP." Subject: Re: [imap5] something to remember in light of recent conversations X-BeenThere: imap5@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion on drastically slimming-down IMAP." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Aug 2011 22:19:52 -0000 On Tue, Aug 02, 2011 at 02:13:14PM -0700, Mark Crispin wrote: > On Tue, 2 Aug 2011, Bron Gondwana wrote: > >No shit - you append it with a new UID. > > Which is a completely new instance of the message, which every > synchronizing client must redownload. True. Luckily, this is a much rarer case than even sending email. Undo being slightly more expensive is not the end of the world, and synchronizing clients with a GUID/DIGEST can redownload much more cheaply. > >Despite your repeated attempts > >to paint me as one, I'm not a blithering moron. > > Then stop acting like one. I disagree with your assertion that wanting to solve problems makes me a moron. I didn't come flying in with no experience, I've been running a mail service for a reasonable amount of time, and also maintaining a server implementation and doing work on clients. > >I don't even know how to start responding to this. The user interface > >paradigm needs an internal representation. > > No it does not. The user interface software maps from whatever internal > representation is present to the paradigm that it presents to the user. Indeed it does. > >I believe in having the computer do extra work so that users don't > >have to. > > If that is the case, then the computer software, not the protocols, should > do the necessary work. It does not mean that protocols must be altered so > that computer software is reduced to a null transform. That's fine, so long as the protocols provide a method to map the user interface's requirements. The issue is that IMAP provides no way to identify that a message is "the same" content, except by it having the same triple (mboxname, uidvalidity, uid). Except for the same client, on the same connection, there's no way to see that you have the same message after a COPY. There's no way to move a message without using extra quota during the move. > >You appear to believe the opposite, that users should change > >their behaviour to make life easier for the computer. I can't cross > >this divide and join you I'm afraid. > > Maybe that is because you persist in making strawman arguments. The same things that annoyed me about IMAP+SMTP 10 years ago still annoy me. I have more experience now to have a good idea of what solutions to them are likely to work if you're trying to solve the problems rather than maintain "protocol purity". At the point where you're working around deficiencies in an API rather than providing the facilities in the API, you get un-necessary complexity. It's my assertion that IMAP clients have a large amount of un-necessary complexity to work around, and that a primary goal of any potential IMAP5 should be reducing that un-necessary complexity - so that indeed the software is as close to a null transform as possible. Layers of transforms and workarounds stacked over each other does not make a good overall system. The protocol is only one component on the system, it doesn't deserve to be raised on a pedestal above all others. The client needs to transmit an intention from the user to the mail store, and the more layers of translation and rewriting that intention goes through, the less clearly it gets articulated. Yes, fashions change, and trying to follow all of them is a losing battle, but never changing to match the reality of how you're actually being used is also a losing battle. Bron. From mrc+ietf@panda.com Tue Aug 2 16:46:41 2011 Return-Path: X-Original-To: imap5@ietfa.amsl.com Delivered-To: imap5@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E15C11E8107 for ; Tue, 2 Aug 2011 16:46:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.252 X-Spam-Level: X-Spam-Status: No, score=-2.252 tagged_above=-999 required=5 tests=[AWL=-0.253, BAYES_00=-2.599, J_CHICKENPOX_22=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GJIQtIy1szjV for ; Tue, 2 Aug 2011 16:46:40 -0700 (PDT) Received: from Panda.COM (panda.com [206.124.149.114]) by ietfa.amsl.com (Postfix) with ESMTP id 72E1E11E8100 for ; Tue, 2 Aug 2011 16:46:40 -0700 (PDT) Received: from hsinghsing.panda.com ([206.124.149.116]) by Panda.COM ([192.107.14.50]) with ESMTP via TCP; Tue, 02 Aug 2011 16:46:40 -0700 X-MailFrom: mrc+ietf@panda.com Date: Tue, 2 Aug 2011 16:46:38 -0700 (PDT) From: Mark Crispin Sender: mrc@hsinghsing.panda.com To: Bron Gondwana In-Reply-To: <20110802221959.GA26605@brong.net> Message-ID: References: <20110802185031.GA13692@brong.net> <9031.1312316256.119145@puncture> <20110802203913.GA15456@brong.net> <20110802210101.GA16087@brong.net> <20110802221959.GA26605@brong.net> User-Agent: Alpine 2.00 (OSX 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Cc: "Discussion on drastically slimming-down IMAP." Subject: Re: [imap5] something to remember in light of recent conversations X-BeenThere: imap5@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion on drastically slimming-down IMAP." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Aug 2011 23:46:41 -0000 On Wed, 3 Aug 2011, Bron Gondwana wrote: > I disagree with your assertion that wanting to solve problems makes > me a moron. Wanting to solve problems does not make you a moron. Demanding that your proferred solution be adopted, to the exclusion of any other approach, makes you a moron. Repeating incessantly "it's all so simple, it is just this trivial change, and the people who say that it is more complicated than that are silly old farts who can't adapt to change" makes you a moron. Insisting that you understand all the issues, and accusing those who disagree of being mindless followers of a "protocol purity" religion, makes you a moron. > I didn't come flying in with no experience, I've been > running a mail service for a reasonable amount of time, and also > maintaining a server implementation and doing work on clients. Knowledge is a dangerous thing, and a little knowledge is the most dangerous of all. The more you learn in the future, the more that you will come to realize how much you do not know. Life is full of seemingly-simple solutions to intractable problems. Disaster results when such false solutions are deployed. It takes experience and wisdom to avoid such mistakes; the latter coming somewhat after the former. The classic example is "what would have happened if Y2K had happened a few years later?" Y2K was a non-issue largely because the WWII generation was still around. > That's fine, so long as the protocols provide a method to map the > user interface's requirements. It is not the responsibility, nor the mission, of the protocol to provide such mapping. Mapping is the responsibility of the consumer of the protocol. > The issue is that IMAP provides no > way to identify that a message is "the same" content, except by it > having the same triple (mboxname, uidvalidity, uid). That would, in turn, point you to the solution if you had the experience and wisdom. > Except for the same client, on the same connection, there's no way > to see that you have the same message after a COPY. RFC 4315. > There's no way to move a message without using extra quota during > the move. Those are server implementation concepts. To put it in UNIX terms, there is no requirement in IMAP that COPY be implemented as a cp rather than an ln. Even if MOVE were added to IMAP, there is (can be) no requirement that a server implement MOVE as an rather than a cp+rm. A protocol specification does not (can not) dictate server implementation specifics. Quota itself is a mentality of systems with limited storage that must be recycled. It is a completely alien concept in the increasing percentage of environments in which is no such thing as storage recycling; "expunge" is merely a "remove from view" but data is retained forever. Now, with this all said, a GUID would be useful in a new IMAP. The horse long ago left that barn for the existing IMAP. Similarly, it is desirable to abolish mailboxes in favor of named views to a single store (thus making the whole COPY/MOVE argument moot); Gmail has the right idea albeit with a wretchedly bad export to existing IMAP. > I have more experience now to have a good idea of what > solutions to them are likely to work if you're trying to solve the > problems rather than maintain "protocol purity". The practice of burning strawmen does not make bogus arguments any more convincing. -- Mark -- http://panda.com/mrc Democracy is two wolves and a sheep deciding what to eat for lunch. Liberty is a well-armed sheep contesting the vote. From gilles.lamiral@laposte.net Tue Aug 2 21:57:30 2011 Return-Path: X-Original-To: imap5@ietfa.amsl.com Delivered-To: imap5@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72FB311E8093 for ; Tue, 2 Aug 2011 21:57:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.556 X-Spam-Level: X-Spam-Status: No, score=-2.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ys20fUN3eHzM for ; Tue, 2 Aug 2011 21:57:29 -0700 (PDT) Received: from ks200821.kimsufi.com (ks200821.kimsufi.com [91.121.112.202]) by ietfa.amsl.com (Postfix) with ESMTP id 9812E11E8087 for ; Tue, 2 Aug 2011 21:57:29 -0700 (PDT) Received: from lamiral.info (lamiral.info [62.147.165.21]) by ks200821.kimsufi.com (Postfix) with ESMTP id DA54D520454 for ; Wed, 3 Aug 2011 06:57:37 +0200 (CEST) Received: from [127.0.0.1] (petite.lamiral.info [127.0.0.1]) by lamiral.info (Postfix) with ESMTP id 26EE92440E1 for ; Wed, 3 Aug 2011 06:57:37 +0200 (CEST) Message-ID: <4E38D540.6070600@laposte.net> Date: Wed, 03 Aug 2011 06:57:36 +0200 From: Gilles LAMIRAL User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.18) Gecko/20110617 Thunderbird/3.1.11 MIME-Version: 1.0 To: imap5@ietf.org References: <20110802185031.GA13692@brong.net> <9031.1312316256.119145@puncture> <20110802203913.GA15456@brong.net> <9031.1312318939.365875@puncture> <20110802213442.GA16293@brong.net> In-Reply-To: <20110802213442.GA16293@brong.net> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [imap5] something to remember in light of recent conversations X-BeenThere: imap5@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion on drastically slimming-down IMAP." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Aug 2011 04:57:30 -0000 Hello, > You're not doing it to "help", you might be at 75% of quota and still > months off being close to the limit, but want to move what amounts to > 50% of your messages. If you move it all at once, you hit the quota, > if you move it in little batches, you don't. Annoying and unintuative. How poor your tools are! You have an ugly server doing stupid IMAP implementation (cp+rm) and stupid quota (while disk space double evey 18 months) and you also have a stupid IMAP client that can't do little batches at your place. So with all that poor and stupid tools you're using on both sides you then ask the protocol to change itself expecting that both sides won't stay poor and stupid to implement the new protocol. They will stay poor and stupid because the issues you describe here (move over quota) can be solved right now easily with the current protocol. -- Au revoir, 09 51 84 42 42 Gilles Lamiral. France, Baulon (35580) 06 20 79 76 06 From brong@fastmail.fm Tue Aug 2 23:24:42 2011 Return-Path: X-Original-To: imap5@ietfa.amsl.com Delivered-To: imap5@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B931C11E80A3 for ; Tue, 2 Aug 2011 23:24:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.539 X-Spam-Level: X-Spam-Status: No, score=-3.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cq8OZMEOORef for ; Tue, 2 Aug 2011 23:24:41 -0700 (PDT) Received: from out2.smtp.messagingengine.com (out2.smtp.messagingengine.com [66.111.4.26]) by ietfa.amsl.com (Postfix) with ESMTP id 6CDD211E8070 for ; Tue, 2 Aug 2011 23:24:41 -0700 (PDT) Received: from compute3.internal (compute3.nyi.mail.srv.osa [10.202.2.43]) by gateway1.messagingengine.com (Postfix) with ESMTP id 3880220BA2; Wed, 3 Aug 2011 02:24:22 -0400 (EDT) Received: from frontend2.messagingengine.com ([10.202.2.161]) by compute3.internal (MEProxy); Wed, 03 Aug 2011 02:24:22 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=date:from:to:cc:subject:message-id :references:mime-version:content-type:in-reply-to; s=smtpout; bh=Ly9LOYylWz4Wrz9m+2K6bQvFjdQ=; b=ZhL5+E2XO7VP5mt53HUlO73Du0Kr Ipe+mwQJTiKcOY+mUvEDXrqqhClQqT06tvYoihYpVNYSlorI4IAcn7bm+0NTPxE1 rLkqD8sWKFEMyvfXnM9vAcyqthDDf2e4aejLpxKix/X8iZJdadfHrcmO53V3aZhy 54JgYo+MM9R1ulQ= X-Sasl-enc: Roqy5yFXLu+2Vk7CSpk7i7iIOCpzeXh7ppFcDwsxG6OU 1312352662 Received: from localhost (56.243.9.46.customer.cdi.no [46.9.243.56]) by mail.messagingengine.com (Postfix) with ESMTPSA id E39DC457570; Wed, 3 Aug 2011 02:24:21 -0400 (EDT) Received: by localhost (Postfix, from userid 1000) id B265E203C0; Wed, 3 Aug 2011 08:24:20 +0200 (CEST) Date: Wed, 3 Aug 2011 08:24:20 +0200 From: Bron Gondwana To: Gilles LAMIRAL Message-ID: <20110803062420.GB6947@brong.net> References: <20110802185031.GA13692@brong.net> <9031.1312316256.119145@puncture> <20110802203913.GA15456@brong.net> <9031.1312318939.365875@puncture> <20110802213442.GA16293@brong.net> <4E38D540.6070600@laposte.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4E38D540.6070600@laposte.net> Organization: brong.net User-Agent: Mutt/1.5.21 (2010-09-15) Cc: imap5@ietf.org Subject: Re: [imap5] something to remember in light of recent conversations X-BeenThere: imap5@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion on drastically slimming-down IMAP." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Aug 2011 06:24:42 -0000 On Wed, Aug 03, 2011 at 06:57:36AM +0200, Gilles LAMIRAL wrote: > > You're not doing it to "help", you might be at 75% of quota and still > > months off being close to the limit, but want to move what amounts to > > 50% of your messages. If you move it all at once, you hit the quota, > > if you move it in little batches, you don't. Annoying and unintuative. > > How poor your tools are! You have an ugly server doing stupid > IMAP implementation (cp+rm) and stupid quota (while disk space double > evey 18 months) and you also have a stupid IMAP client > that can't do little batches at your place. Argument doesn't hold up when you have large numbers of people paying a small amount of money to use a service - you need to have quotas of some sort. We could possibly change the server so that multiple copies of the same message didn't count towards quota - they don't use any additional space on the server (well, not much) because of hardlinks. This would indeed be a workaround, if somewhat confusing. But yes, that could be a way to solve our individual case. > So with all that poor and stupid tools you're using on both sides > you then ask the protocol to change itself expecting that both sides > won't stay poor and stupid to implement the new protocol. > They will stay poor and stupid because the issues you describe > here (move over quota) can be solved right now easily with the > current protocol. Actually, they can't without making the server not charge quota for the move. Sure you can do small batches, but you need to guess what size is "small enough", and it's going to be a bigger IO hit for the server and bandwidth hit if you guess wrong. In other words you're working around the fact that the protocol doesn't allow you to express your intention directly to the server. Bron. From gilles.lamiral@laposte.net Wed Aug 3 00:07:19 2011 Return-Path: X-Original-To: imap5@ietfa.amsl.com Delivered-To: imap5@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EDD511E8090 for ; Wed, 3 Aug 2011 00:07:19 -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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FH9Ud2Su-AZO for ; Wed, 3 Aug 2011 00:07:18 -0700 (PDT) Received: from ks200821.kimsufi.com (ks200821.kimsufi.com [91.121.112.202]) by ietfa.amsl.com (Postfix) with ESMTP id 9343311E8086 for ; Wed, 3 Aug 2011 00:07:18 -0700 (PDT) Received: from lamiral.info (lamiral.info [62.147.165.21]) by ks200821.kimsufi.com (Postfix) with ESMTP id 7317A520454; Wed, 3 Aug 2011 09:07:27 +0200 (CEST) Received: from [127.0.0.1] (petite.lamiral.info [127.0.0.1]) by lamiral.info (Postfix) with ESMTP id B9DDB2440E1; Wed, 3 Aug 2011 09:07:25 +0200 (CEST) Message-ID: <4E38F3AD.5030501@laposte.net> Date: Wed, 03 Aug 2011 09:07:25 +0200 From: Gilles LAMIRAL User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.18) Gecko/20110617 Thunderbird/3.1.11 MIME-Version: 1.0 To: Bron Gondwana References: <20110802185031.GA13692@brong.net> <9031.1312316256.119145@puncture> <20110802203913.GA15456@brong.net> <9031.1312318939.365875@puncture> <20110802213442.GA16293@brong.net> <4E38D540.6070600@laposte.net> <20110803062420.GB6947@brong.net> In-Reply-To: <20110803062420.GB6947@brong.net> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: imap5@ietf.org Subject: Re: [imap5] something to remember in light of recent conversations X-BeenThere: imap5@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion on drastically slimming-down IMAP." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Aug 2011 07:07:19 -0000 Hello, > Argument doesn't hold up when you have large numbers of people paying > a small amount of money to use a service - you need to have quotas of > some sort. Ok. Just write an imap server implementation allowing a move within quota. Easy. > We could possibly change the server so that multiple copies of the > same message didn't count towards quota - they don't use any additional > space on the server (well, not much) because of hardlinks. This would > indeed be a workaround, if somewhat confusing. So do it. They are other ways to do it. > Actually, they can't without making the server not charge quota for > the move. Sure you can do small batches, but you need to guess what > size is "small enough", and it's going to be a bigger IO hit for the > server and bandwidth hit if you guess wrong. This client change only has to be considered if the server stay poor and stupid. In that case one message at a time will do the job. And bandwidth increase for the IMAP commands is peanuts. > In other words you're working around the fact that the protocol doesn't > allow you to express your intention directly to the server. I'm working around the fact you have poor and stupid tools on both sides you don't master with peanuts bandwith constraints and false marketing ones, "my clients pay so few I can't add a 2TB hard disk costing 100 USD". 5 cents for 1 GB is to much? Wait 18 months it will be 2 cents. -- Au revoir, 09 51 84 42 42 Gilles Lamiral. France, Baulon (35580) 06 20 79 76 06 From brong@fastmail.fm Wed Aug 3 00:43:12 2011 Return-Path: X-Original-To: imap5@ietfa.amsl.com Delivered-To: imap5@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8AC2321F8B2E for ; Wed, 3 Aug 2011 00:43:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.179 X-Spam-Level: X-Spam-Status: No, score=-3.179 tagged_above=-999 required=5 tests=[AWL=-0.180, BAYES_00=-2.599, J_CHICKENPOX_22=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 57v0-UdmqhQy for ; Wed, 3 Aug 2011 00:43:11 -0700 (PDT) Received: from out2.smtp.messagingengine.com (out2.smtp.messagingengine.com [66.111.4.26]) by ietfa.amsl.com (Postfix) with ESMTP id 891E321F8B20 for ; Wed, 3 Aug 2011 00:43:11 -0700 (PDT) Received: from compute3.internal (compute3.nyi.mail.srv.osa [10.202.2.43]) by gateway1.messagingengine.com (Postfix) with ESMTP id ACE4620B35; Wed, 3 Aug 2011 03:43:11 -0400 (EDT) Received: from frontend1.messagingengine.com ([10.202.2.160]) by compute3.internal (MEProxy); Wed, 03 Aug 2011 03:43:11 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=content-type:to:cc:subject:references :date:mime-version:content-transfer-encoding:from:message-id :in-reply-to; s=smtpout; bh=D9QOHR1spkMujtwdZeGdkjtpJso=; b=Gt+M pBdnO724fgHt6y9MpRL/CyHOLs8u/gsZ9JQkbC3agyvE+uD0i7NimK9pi9ca85W+ SlS5zUPUgaxcV22TJCzSYcz2NVP/Zw5g179IygioF143h59HMZWVz54PBbpneMEp PQe/asTgCL2WNftPnbHZUW/DBnNc9PN5PygOAMA= X-Sasl-enc: RNwH1R0fLGpCryDBzZCw59f0LW82yQi8RccX06IO6f+l 1312357391 Received: from arbre.eng.oslo.osa (pat-tdc.opera.com [213.236.208.22]) by mail.messagingengine.com (Postfix) with ESMTPSA id 01E484017AB; Wed, 3 Aug 2011 03:43:10 -0400 (EDT) Content-Type: text/plain; charset=utf-8; format=flowed; delsp=yes To: "Mark Crispin" References: <20110802185031.GA13692@brong.net> <9031.1312316256.119145@puncture> <20110802203913.GA15456@brong.net> <20110802210101.GA16087@brong.net> <20110802221959.GA26605@brong.net> Date: Wed, 03 Aug 2011 09:43:12 +0200 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: "Bron Gondwana" Organization: FastMail.FM Message-ID: In-Reply-To: User-Agent: Opera Mail/11.50 (Linux) Cc: "Discussion on drastically slimming-down IMAP." Subject: Re: [imap5] something to remember in light of recent conversations X-BeenThere: imap5@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion on drastically slimming-down IMAP." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Aug 2011 07:43:12 -0000 On Wed, 03 Aug 2011 01:46:38 +0200, Mark Crispin wrote: > On Wed, 3 Aug 2011, Bron Gondwana wrote: >> I disagree with your assertion that wanting to solve problems makes >> me a moron. > > Wanting to solve problems does not make you a moron. > > Demanding that your proferred solution be adopted, to the exclusion of > any > other approach, makes you a moron. I'm happy with another solution, so long as it actually solves the problems that are hampering the current approaches. > Life is full of seemingly-simple solutions to intractable problems. > Disaster results when such false solutions are deployed. It takes > experience and wisdom to avoid such mistakes; the latter coming somewhat > after the former. Life is also full of seemingly complex problems which are only complex because you're doing it wrong. For example generating sendmail.cf from m4 and then generating THAT from another language because m4 is too complex/ugly as well. And then putting a firewall in front of sendmail that does stateful inspection because sendmail is too riddled with security holes due to its architecture. Or you could do what quite a few have done since which is build a modular server with a configuration file syntax that wasn't designed to make things easier for the computer, but instead to make configuring the most common servers easier, and more complex ones possible. > The classic example is "what would have happened if Y2K had happened a > few > years later?" Y2K was a non-issue largely because the WWII generation > was > still around. Woah. I take it back, you're not just saying I'm a moron, you're saying that everyone born after you is a moron. Well, I guess it doesn't matter what I try then, because once the WWII generation die off, we're all royally f^&*ed. This is a massive tangent from the original discussion, but Y2K was largely caused by making things simpler for the computer, because computers didn't have the capacity to waste on extra bytes. Later in this same email you argue that quotas are a temporary artifact of artificial scarcity which will disappear. I think you're at least partially right there. It was also exacerbated by the source code to many systems being no longer available. Thankfully, things are a bit better now, with most programmers using some form of source control. I was disappointed, looking back at my degree, how poorly source control was taught. They spent ages talking about waterfall, but didn't get us using RCS (yeah, guess what we were taught) or CVS right at the start. I had to learn to love source control on my own time - because you can't love CVS. >> That's fine, so long as the protocols provide a method to map the >> user interface's requirements. > > It is not the responsibility, nor the mission, of the protocol to provide > such mapping. Mapping is the responsibility of the consumer of the > protocol. Nonsense - clarity of communication is a responsibility of the whole stack. If there is no clear way to communicate the intention of the user to the server, then the server is left to infer the user's intent by reverse engineering the operations it sees over the protocol. If the set of actions that users want to perform doesn't mesh well with the protocol, then >> The issue is that IMAP provides no >> way to identify that a message is "the same" content, except by it >> having the same triple (mboxname, uidvalidity, uid). > > That would, in turn, point you to the solution if you had the experience > and wisdom. That's nice. I'm presuming you mean "mark it \Deleted but don't expunge it". That's not a solution in a world where a different session can complete the delete for you without meaning to. If there was no EXPUNGE, only UID EXPUNGE, then I would be happy to agree, but that ship has sailed. You can't trust it in the arbitrary case, and it dirties up the view in existing clients. >> Except for the same client, on the same connection, there's no way ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >> to see that you have the same message after a COPY. > > RFC 4315. Um ...how RFC 4315 provides the information about it being the same message to anyone other than the client that actually does the copy? Every other connected client has no semantic information and no way to get it. >> There's no way to move a message without using extra quota during >> the move. > > Those are server implementation concepts. > > To put it in UNIX terms, there is no requirement in IMAP that COPY be > implemented as a cp rather than an ln. > > Even if MOVE were added to IMAP, there is (can be) no requirement that a > server implement MOVE as an rather than a cp+rm. > > A protocol specification does not (can not) dictate server implementation > specifics. It can dictate things like "A must happen before B" though. Or at least "it must not be possible for B to happen without A happening as well", which means you can either do atomic, or A then B, but not B then A. > Quota itself is a mentality of systems with limited storage that must be > recycled. It is a completely alien concept in the increasing percentage > of environments in which is no such thing as storage recycling; "expunge" > is merely a "remove from view" but data is retained forever. Such environments still have abuse controls of some sort. Hanging infinite uncontrolled storage out over any protocol to untrusted users causes problems. > Now, with this all said, a GUID would be useful in a new IMAP. The horse > long ago left that barn for the existing IMAP. Similarly, it is > desirable > to abolish mailboxes in favor of named views to a single store (thus > making the whole COPY/MOVE argument moot); Gmail has the right idea > albeit > with a wretchedly bad export to existing IMAP. Let's write that protocol then. Bron From brong@fastmail.fm Wed Aug 3 00:52:21 2011 Return-Path: X-Original-To: imap5@ietfa.amsl.com Delivered-To: imap5@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6342521F8B30 for ; Wed, 3 Aug 2011 00:52:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.543 X-Spam-Level: X-Spam-Status: No, score=-2.543 tagged_above=-999 required=5 tests=[AWL=-0.756, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_SPEC_REPLICA_OBFU=1.812] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HLLxdKLONC9l for ; Wed, 3 Aug 2011 00:52:20 -0700 (PDT) Received: from out2.smtp.messagingengine.com (out2.smtp.messagingengine.com [66.111.4.26]) by ietfa.amsl.com (Postfix) with ESMTP id C87B821F8B2E for ; Wed, 3 Aug 2011 00:52:20 -0700 (PDT) Received: from compute1.internal (compute1.nyi.mail.srv.osa [10.202.2.41]) by gateway1.messagingengine.com (Postfix) with ESMTP id 0D94420BC2; Wed, 3 Aug 2011 03:52:32 -0400 (EDT) Received: from frontend1.messagingengine.com ([10.202.2.160]) by compute1.internal (MEProxy); Wed, 03 Aug 2011 03:52:32 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=content-type:to:cc:subject:references :date:mime-version:content-transfer-encoding:from:message-id :in-reply-to; s=smtpout; bh=YMxLAoeyooKSeDhOy1+6qZcdaW8=; b=Wszp 3ckdwoFnOmqO+n+SD7gi2FfyKwtI5f5Ijb29/OXUbAWKR/eq75hIQ/A0cNWrf0ZY 7KmSl/5qBl6HxUvILFJCT+aJTr1V3nVEhZ/CgehEW0wTfL1y2exRHjFF+/g8mQPm meRFu2UlvYMB7cF4yxVDqemxg+Gwk+w9Rc/CzLU= X-Sasl-enc: gSwdeKfupJXxTViMCCI1uXgEIOwLIY+sMYvXmb45kVIk 1312357951 Received: from arbre.eng.oslo.osa (pat-tdc.opera.com [213.236.208.22]) by mail.messagingengine.com (Postfix) with ESMTPSA id 7A83C416954; Wed, 3 Aug 2011 03:52:31 -0400 (EDT) Content-Type: text/plain; charset=utf-8; format=flowed; delsp=yes To: "Gilles LAMIRAL" References: <20110802185031.GA13692@brong.net> <9031.1312316256.119145@puncture> <20110802203913.GA15456@brong.net> <9031.1312318939.365875@puncture> <20110802213442.GA16293@brong.net> <4E38D540.6070600@laposte.net> <20110803062420.GB6947@brong.net> <4E38F3AD.5030501@laposte.net> Date: Wed, 03 Aug 2011 09:52:33 +0200 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: "Bron Gondwana" Organization: FastMail.FM Message-ID: In-Reply-To: <4E38F3AD.5030501@laposte.net> User-Agent: Opera Mail/11.50 (Linux) Cc: imap5@ietf.org Subject: Re: [imap5] something to remember in light of recent conversations X-BeenThere: imap5@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion on drastically slimming-down IMAP." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Aug 2011 07:52:21 -0000 On Wed, 03 Aug 2011 09:07:25 +0200, Gilles LAMIRAL wrote: > I'm working around the fact you have poor and stupid tools on both sides > you don't master with peanuts bandwith constraints and false marketing > ones, "my clients pay so few I can't add a 2TB hard disk costing 100 > USD". > 5 cents for 1 GB is to much? Wait 18 months it will be 2 cents. I think we calculated it costs us about 35c per gigabyte of email, purely for storage. That's RAID1, metadata on SSD, one onsite live replica, one offsite live replica, plus a separate backup. Then there's server costs, maintenance, abuse management, support, deprecation, etc. A 2Tb consumer hard disk is so clearly not equivalent to the cost of running a complete service that I can't believe you would propose it. Bron. -- Using Opera's revolutionary email client: http://www.opera.com/mail/ From gilles.lamiral@laposte.net Wed Aug 3 01:28:05 2011 Return-Path: X-Original-To: imap5@ietfa.amsl.com Delivered-To: imap5@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 100E021F86CA for ; Wed, 3 Aug 2011 01:28:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.66 X-Spam-Level: X-Spam-Status: No, score=-1.66 tagged_above=-999 required=5 tests=[AWL=-0.873, BAYES_00=-2.599, SARE_SPEC_REPLICA_OBFU=1.812] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u+f+9G01rcHg for ; Wed, 3 Aug 2011 01:28:04 -0700 (PDT) Received: from ks200821.kimsufi.com (ks200821.kimsufi.com [91.121.112.202]) by ietfa.amsl.com (Postfix) with ESMTP id 8C9C021F86AF for ; Wed, 3 Aug 2011 01:28:04 -0700 (PDT) Received: from lamiral.info (lamiral.info [62.147.165.21]) by ks200821.kimsufi.com (Postfix) with ESMTP id BE652520454; Wed, 3 Aug 2011 10:28:13 +0200 (CEST) Received: from [127.0.0.1] (petite.lamiral.info [127.0.0.1]) by lamiral.info (Postfix) with ESMTP id B19132440E1; Wed, 3 Aug 2011 10:28:12 +0200 (CEST) Message-ID: <4E39069C.6060409@laposte.net> Date: Wed, 03 Aug 2011 10:28:12 +0200 From: Gilles LAMIRAL User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.18) Gecko/20110617 Thunderbird/3.1.11 MIME-Version: 1.0 To: Bron Gondwana References: <20110802185031.GA13692@brong.net> <9031.1312316256.119145@puncture> <20110802203913.GA15456@brong.net> <9031.1312318939.365875@puncture> <20110802213442.GA16293@brong.net> <4E38D540.6070600@laposte.net> <20110803062420.GB6947@brong.net> <4E38F3AD.5030501@laposte.net> In-Reply-To: X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: imap5@ietf.org Subject: Re: [imap5] something to remember in light of recent conversations X-BeenThere: imap5@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion on drastically slimming-down IMAP." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Aug 2011 08:28:05 -0000 Hello, > I think we calculated it costs us about 35c per gigabyte of email, > purely for storage. That's RAID1, metadata on SSD, one onsite live > replica, one offsite live replica, plus a separate backup. And how much your clients pay per month for how many GB? > Then there's server costs, maintenance, abuse management, support, > deprecation, etc. So continue to give all the cost numbers, I already know we'll all smile when we do the difference between what cost your current whole system and what will cost the future whole system with all the imap change you ask. Peanut dust. > A 2Tb consumer hard disk is so clearly not equivalent to the cost of > running a complete service that I can't believe you would propose it. If I had so poor clients as you mean to deal with I certainly would use 2Tb consumer hard disks. May be you know what Google use as hard disks? The poor consumer ones. Really. Follow them, they do know why they've done that choice, technically and commercially speaking. -- Au revoir, 09 51 84 42 42 Gilles Lamiral. France, Baulon (35580) 06 20 79 76 06 From brong@fastmail.fm Wed Aug 3 01:47:45 2011 Return-Path: X-Original-To: imap5@ietfa.amsl.com Delivered-To: imap5@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6218121F86BB for ; Wed, 3 Aug 2011 01:47:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.435 X-Spam-Level: X-Spam-Status: No, score=-2.435 tagged_above=-999 required=5 tests=[AWL=-0.648, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_SPEC_REPLICA_OBFU=1.812] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5w7bmBI8F+PR for ; Wed, 3 Aug 2011 01:47:44 -0700 (PDT) Received: from out2.smtp.messagingengine.com (out2.smtp.messagingengine.com [66.111.4.26]) by ietfa.amsl.com (Postfix) with ESMTP id 9C2AD21F8686 for ; Wed, 3 Aug 2011 01:47:44 -0700 (PDT) Received: from compute5.internal (compute5.nyi.mail.srv.osa [10.202.2.45]) by gateway1.messagingengine.com (Postfix) with ESMTP id EFDD9202E3; Wed, 3 Aug 2011 04:47:55 -0400 (EDT) Received: from frontend2.messagingengine.com ([10.202.2.161]) by compute5.internal (MEProxy); Wed, 03 Aug 2011 04:47:55 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=content-type:to:cc:subject:references :date:mime-version:content-transfer-encoding:from:message-id :in-reply-to; s=smtpout; bh=AHQ2RRhh4J4IzGNSRc3rqtbVYZI=; b=oHIf D02XYsmysku+VSYV9QZpYQomtkctIubrJfIuCiP8Q5zKfsiZwuKMi/tP1JqMwRuL NgUKMVN6rZbD3zB8onpuLb7RR0LRPKAcwXb4oWMVSM4s1/ANvPkT1siqm0BHI4I4 TKqMtgHkfcw9R1tJqVfHQjOV48HHCL6o+z5TwYU= X-Sasl-enc: wyxl0Cwy8XX7Yc1iIu9ijlOvySZeOwDQrh38lKNJ5BoD 1312361275 Received: from arbre.eng.oslo.osa (pat-tdc.opera.com [213.236.208.22]) by mail.messagingengine.com (Postfix) with ESMTPSA id 6589245790A; Wed, 3 Aug 2011 04:47:55 -0400 (EDT) Content-Type: text/plain; charset=utf-8; format=flowed; delsp=yes To: "Gilles LAMIRAL" References: <20110802185031.GA13692@brong.net> <9031.1312316256.119145@puncture> <20110802203913.GA15456@brong.net> <9031.1312318939.365875@puncture> <20110802213442.GA16293@brong.net> <4E38D540.6070600@laposte.net> <20110803062420.GB6947@brong.net> <4E38F3AD.5030501@laposte.net> <4E39069C.6060409@laposte.net> Date: Wed, 03 Aug 2011 10:47:57 +0200 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: "Bron Gondwana" Organization: FastMail.FM Message-ID: In-Reply-To: <4E39069C.6060409@laposte.net> User-Agent: Opera Mail/11.50 (Linux) Cc: imap5@ietf.org Subject: Re: [imap5] something to remember in light of recent conversations X-BeenThere: imap5@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion on drastically slimming-down IMAP." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Aug 2011 08:47:45 -0000 On Wed, 03 Aug 2011 10:28:12 +0200, Gilles LAMIRAL wrote: > Hello, > >> I think we calculated it costs us about 35c per gigabyte of email, >> purely for storage. That's RAID1, metadata on SSD, one onsite live >> replica, one offsite live replica, plus a separate backup. > > And how much your clients pay per month for how many GB? More than that. Like I said, that's JUST storage. >> Then there's server costs, maintenance, abuse management, support, >> deprecation, etc. > > So continue to give all the cost numbers, I already know we'll all > smile when we do the difference between what cost your current whole > system and what will cost the future whole system with all the imap > change you ask. Peanut dust. I don't precisely see what that has to do with making MOVE not affected by quota. >> A 2Tb consumer hard disk is so clearly not equivalent to the cost of >> running a complete service that I can't believe you would propose it. > > If I had so poor clients as you mean to deal with I certainly > would use 2Tb consumer hard disks. I pity your clients. There's a middle ground between "gold plated" and "dirt cheap no redundancy". We keep the raw emails on 2Tb consumer hard disks, mostly, but not on just a single one. > May be you know what Google use as hard disks? > The poor consumer ones. Really. Follow them, > they do know why they've done that choice, technically > and commercially speaking. Same reason we did - it's dirt cheap and performance and reliability is sufficient if you have additional layers of indexing on faster drives and redundancy to get around the lower reliability. None of which is relevant to the argument about whether quotas are required to avoid rampant abuse, or whether a way to move messages within the same quotaroot without having to check if you're playing chicken with the limit is worthwhile. -- Using Opera's revolutionary email client: http://www.opera.com/mail/ From gilles.lamiral@laposte.net Wed Aug 3 02:29:47 2011 Return-Path: X-Original-To: imap5@ietfa.amsl.com Delivered-To: imap5@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 301BA21F8B12 for ; Wed, 3 Aug 2011 02:29:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.478 X-Spam-Level: X-Spam-Status: No, score=-2.478 tagged_above=-999 required=5 tests=[AWL=0.121, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1GfcE4okZlMo for ; Wed, 3 Aug 2011 02:29:46 -0700 (PDT) Received: from ks200821.kimsufi.com (ks200821.kimsufi.com [91.121.112.202]) by ietfa.amsl.com (Postfix) with ESMTP id A4D3721F8ADE for ; Wed, 3 Aug 2011 02:29:46 -0700 (PDT) Received: from lamiral.info (lamiral.info [62.147.165.21]) by ks200821.kimsufi.com (Postfix) with ESMTP id 6426B520454; Wed, 3 Aug 2011 11:29:56 +0200 (CEST) Received: from [127.0.0.1] (petite.lamiral.info [127.0.0.1]) by lamiral.info (Postfix) with ESMTP id E10DB2440E1; Wed, 3 Aug 2011 11:29:54 +0200 (CEST) Message-ID: <4E391512.708@laposte.net> Date: Wed, 03 Aug 2011 11:29:54 +0200 From: Gilles LAMIRAL User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.18) Gecko/20110617 Thunderbird/3.1.11 MIME-Version: 1.0 To: Bron Gondwana References: <20110802185031.GA13692@brong.net> <9031.1312316256.119145@puncture> <20110802203913.GA15456@brong.net> <9031.1312318939.365875@puncture> <20110802213442.GA16293@brong.net> <4E38D540.6070600@laposte.net> <20110803062420.GB6947@brong.net> <4E38F3AD.5030501@laposte.net> <4E39069C.6060409@laposte.net> In-Reply-To: X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: imap5@ietf.org Subject: Re: [imap5] something to remember in light of recent conversations X-BeenThere: imap5@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion on drastically slimming-down IMAP." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Aug 2011 09:29:47 -0000 Hello, >> And how much your clients pay per month for how many GB? > More than that. Like I said, that's JUST storage. What they pay for storage? >> So continue to give all the cost numbers, I already know we'll all >> smile when we do the difference between what cost your current whole >> system and what will cost the future whole system with all the imap >> change you ask. Peanut dust. > > I don't precisely see what that has to do with making MOVE not > affected by quota. Good if you don't see what that has to do with making MOVE not affected by quota. So do I. Just don't invoke storage cost in your argumentation and don't invoke extra "server costs, maintenance, abuse management, support, deprecation" meaning nothing to you in the discussion. > I pity your clients. They're laughing because I don't poison them with quotas, I monitor disk spaces and buy terabytes when needed, before needed. No one has ever cried by moving messages. They pay for this. > There's a middle ground between "gold plated" > and "dirt cheap no redundancy". We keep the raw emails on 2Tb consumer > hard disks, mostly, but not on just a single one. The argument is exactly the same for 35 cents per GB. How much your clients pay per month for how many GB for storage? Stop extra false arguments before replying the question. -- Au revoir, 09 51 84 42 42 Gilles Lamiral. France, Baulon (35580) 06 20 79 76 06 From brong@fastmail.fm Wed Aug 3 02:46:36 2011 Return-Path: X-Original-To: imap5@ietfa.amsl.com Delivered-To: imap5@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE38321F8B28 for ; Wed, 3 Aug 2011 02:46:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.26 X-Spam-Level: X-Spam-Status: No, score=-3.26 tagged_above=-999 required=5 tests=[AWL=0.339, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2Vi-986gBFVk for ; Wed, 3 Aug 2011 02:46:36 -0700 (PDT) Received: from out2.smtp.messagingengine.com (out2.smtp.messagingengine.com [66.111.4.26]) by ietfa.amsl.com (Postfix) with ESMTP id 29BBF21F8B25 for ; Wed, 3 Aug 2011 02:46:36 -0700 (PDT) Received: from compute3.internal (compute3.nyi.mail.srv.osa [10.202.2.43]) by gateway1.messagingengine.com (Postfix) with ESMTP id 9B66D20526; Wed, 3 Aug 2011 05:46:47 -0400 (EDT) Received: from frontend1.messagingengine.com ([10.202.2.160]) by compute3.internal (MEProxy); Wed, 03 Aug 2011 05:46:47 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=content-type:to:cc:subject:references :date:mime-version:content-transfer-encoding:from:message-id :in-reply-to; s=smtpout; bh=bs9hV6s4glVQ5C9aj9uMzs1eh04=; b=jG9Y C59L5vZIJH89DYAkmTCy//lxG5F9WM4LWHLwTjwcW57wm2tCw6YJ/dXJEXX+4CbS fxeOeozkwmTWuHVesPIF+9sXm4lr+NrcFVjgBWGQNkKUFNDKk1tbKn4Iy8CXGahJ +FoZbxsO89opwTPOz+6g3mbYhEztPL/4U1gGtpY= X-Sasl-enc: fTk+RPShSBd84MT4Hry8DIlEDwG+p1PGWWnfeHjArAJZ 1312364807 Received: from arbre.eng.oslo.osa (pat-tdc.opera.com [213.236.208.22]) by mail.messagingengine.com (Postfix) with ESMTPSA id 12BEA415301; Wed, 3 Aug 2011 05:46:46 -0400 (EDT) Content-Type: text/plain; charset=utf-8; format=flowed; delsp=yes To: "Gilles LAMIRAL" References: <20110802185031.GA13692@brong.net> <9031.1312316256.119145@puncture> <20110802203913.GA15456@brong.net> <9031.1312318939.365875@puncture> <20110802213442.GA16293@brong.net> <4E38D540.6070600@laposte.net> <20110803062420.GB6947@brong.net> <4E38F3AD.5030501@laposte.net> <4E39069C.6060409@laposte.net> <4E391512.708@laposte.net> Date: Wed, 03 Aug 2011 11:46:48 +0200 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: "Bron Gondwana" Organization: FastMail.FM Message-ID: In-Reply-To: <4E391512.708@laposte.net> User-Agent: Opera Mail/11.50 (Linux) Cc: imap5@ietf.org Subject: Re: [imap5] something to remember in light of recent conversations X-BeenThere: imap5@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion on drastically slimming-down IMAP." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Aug 2011 09:46:37 -0000 On Wed, 03 Aug 2011 11:29:54 +0200, Gilles LAMIRAL wrote: > Hello, > >>> And how much your clients pay per month for how many GB? >> More than that. Like I said, that's JUST storage. > > What they pay for storage? No - they pay for an entire service. The fact that they don't pay an infinite amount means that storage must be restricted in some way, because it has a cost. Some of them pay nothing at all. >>> So continue to give all the cost numbers, I already know we'll all >>> smile when we do the difference between what cost your current whole >>> system and what will cost the future whole system with all the imap >>> change you ask. Peanut dust. >> >> I don't precisely see what that has to do with making MOVE not >> affected by quota. > > Good if you don't see what that has to do with making MOVE not > affected by quota. So do I. Just don't invoke storage cost in > your argumentation and don't invoke extra "server costs, maintenance, > abuse management, support, deprecation" meaning nothing to you in > the discussion. If you have quotas at all, this becomes an issue. If you don't have quotas, sure, no problem. >> I pity your clients. > > They're laughing because I don't poison them with quotas, > I monitor disk spaces and buy terabytes when needed, before needed. > No one has ever cried by moving messages. They pay for this. Good for you. Do you provide free accounts as well? How do you stop abuse? >> There's a middle ground between "gold plated" >> and "dirt cheap no redundancy". We keep the raw emails on 2Tb consumer >> hard disks, mostly, but not on just a single one. > > The argument is exactly the same for 35 cents per GB. > How much your clients pay per month for how many GB for storage? > Stop extra false arguments before replying the question. https://www.fastmail.fm/mail/personal.html https://www.fastmail.fm/mail/businessplans.html There will be different pricing structures for the Opera branded services, but I don't think they're fixed yet, and even if they were I wouldn't be allowed to tell the world before we announced them officially. Bron. -- Using Opera's revolutionary email client: http://www.opera.com/mail/ From brong@fastmail.fm Wed Aug 3 03:18:31 2011 Return-Path: X-Original-To: imap5@ietfa.amsl.com Delivered-To: imap5@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC6A921F8B4E for ; Wed, 3 Aug 2011 03:18:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.298 X-Spam-Level: X-Spam-Status: No, score=-3.298 tagged_above=-999 required=5 tests=[AWL=0.301, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Oz1D7lQGiKTn for ; Wed, 3 Aug 2011 03:18:31 -0700 (PDT) Received: from out2.smtp.messagingengine.com (out2.smtp.messagingengine.com [66.111.4.26]) by ietfa.amsl.com (Postfix) with ESMTP id F022F21F8B4B for ; Wed, 3 Aug 2011 03:18:30 -0700 (PDT) Received: from compute4.internal (compute4.nyi.mail.srv.osa [10.202.2.44]) by gateway1.messagingengine.com (Postfix) with ESMTP id 7479220C9A; Wed, 3 Aug 2011 06:18:42 -0400 (EDT) Received: from frontend2.messagingengine.com ([10.202.2.161]) by compute4.internal (MEProxy); Wed, 03 Aug 2011 06:18:42 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=content-type:to:cc:subject:references :date:mime-version:content-transfer-encoding:from:message-id :in-reply-to; s=smtpout; bh=F4utC4+KW9lwPsW+NxTY3IIDkZ4=; b=ZjFu opexseBEDot9gccOkb+dAq93WsIM1ZWl564CGQIwSBsAQWBcUT78fQgEuC06/98p pSZm0AL4DrED2kXufxWjWePusVAA/20wVyZcvzN81ktZYJ8ErF3xEtqDkQCKfYy9 04ju3VyZaj0vEPFhwc67/Am4eoBLigKQMjr+Hik= X-Sasl-enc: JjXRZ3G60h0JicSHM1/70l9keJrE6hhHJxHpnn0RnjJA 1312366722 Received: from arbre.eng.oslo.osa (pat-tdc.opera.com [213.236.208.22]) by mail.messagingengine.com (Postfix) with ESMTPSA id BDE8A457C9F; Wed, 3 Aug 2011 06:18:41 -0400 (EDT) Content-Type: text/plain; charset=utf-8; format=flowed; delsp=yes To: "Gilles LAMIRAL" , "Bron Gondwana" References: <20110802185031.GA13692@brong.net> <9031.1312316256.119145@puncture> <20110802203913.GA15456@brong.net> <9031.1312318939.365875@puncture> <20110802213442.GA16293@brong.net> <4E38D540.6070600@laposte.net> <20110803062420.GB6947@brong.net> <4E38F3AD.5030501@laposte.net> <4E39069C.6060409@laposte.net> <4E391512.708@laposte.net> Date: Wed, 03 Aug 2011 12:18:43 +0200 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: "Bron Gondwana" Organization: FastMail.FM Message-ID: In-Reply-To: User-Agent: Opera Mail/11.50 (Linux) Cc: imap5@ietf.org Subject: Re: [imap5] something to remember in light of recent conversations X-BeenThere: imap5@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion on drastically slimming-down IMAP." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Aug 2011 10:18:31 -0000 On Wed, 03 Aug 2011 11:46:48 +0200, Bron Gondwana wrote: >> The argument is exactly the same for 35 cents per GB. >> How much your clients pay per month for how many GB for storage? >> Stop extra false arguments before replying the question. > > https://www.fastmail.fm/mail/personal.html > https://www.fastmail.fm/mail/businessplans.html While we're waving our "how much do your clients pay for your excellent service" wands around - I tried to go to: https://compte.laposte.net/inscription/etape1.do but I get a zero-byte response. So how much do your clients pay, and how much space do you give them before you start charging more? -- Using Opera's revolutionary email client: http://www.opera.com/mail/ From gilles.lamiral@laposte.net Wed Aug 3 08:35:50 2011 Return-Path: X-Original-To: imap5@ietfa.amsl.com Delivered-To: imap5@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4485E21F8B00 for ; Wed, 3 Aug 2011 08:35:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.489 X-Spam-Level: X-Spam-Status: No, score=-2.489 tagged_above=-999 required=5 tests=[AWL=0.110, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zk9MHVC2XsCp for ; Wed, 3 Aug 2011 08:35:49 -0700 (PDT) Received: from ks200821.kimsufi.com (ks200821.kimsufi.com [91.121.112.202]) by ietfa.amsl.com (Postfix) with ESMTP id 8870421F8AFD for ; Wed, 3 Aug 2011 08:35:49 -0700 (PDT) Received: from lamiral.info (lamiral.info [62.147.165.21]) by ks200821.kimsufi.com (Postfix) with ESMTP id 224F7520454; Wed, 3 Aug 2011 17:36:00 +0200 (CEST) Received: from [127.0.0.1] (petite.lamiral.info [127.0.0.1]) by lamiral.info (Postfix) with ESMTP id 84DAE2440E1; Wed, 3 Aug 2011 17:35:59 +0200 (CEST) Message-ID: <4E396ADF.2000106@laposte.net> Date: Wed, 03 Aug 2011 17:35:59 +0200 From: Gilles LAMIRAL User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.18) Gecko/20110617 Thunderbird/3.1.11 MIME-Version: 1.0 To: Bron Gondwana References: <20110802185031.GA13692@brong.net> <9031.1312316256.119145@puncture> <20110802203913.GA15456@brong.net> <9031.1312318939.365875@puncture> <20110802213442.GA16293@brong.net> <4E38D540.6070600@laposte.net> <20110803062420.GB6947@brong.net> <4E38F3AD.5030501@laposte.net> <4E39069C.6060409@laposte.net> <4E391512.708@laposte.net> In-Reply-To: X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: imap5@ietf.org Subject: Re: [imap5] something to remember in light of recent conversations X-BeenThere: imap5@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion on drastically slimming-down IMAP." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Aug 2011 15:35:50 -0000 Hi, > So how much do your clients pay, and how much space do you give > them before you start charging more? Here I'm the client. It's free for 10 GB. -- Au revoir, 09 51 84 42 42 Gilles Lamiral. France, Baulon (35580) 06 20 79 76 06 From jkt@gentoo.org Wed Aug 3 01:34:18 2011 Return-Path: X-Original-To: imap5@ietfa.amsl.com Delivered-To: imap5@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1789B21F8B1B for ; Wed, 3 Aug 2011 01:34:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.95 X-Spam-Level: X-Spam-Status: No, score=-0.95 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 08ri3gugaH8Q for ; Wed, 3 Aug 2011 01:34:17 -0700 (PDT) Received: from serv132.fzu.cz (serv132.fzu.cz [147.231.26.132]) by ietfa.amsl.com (Postfix) with ESMTP id CAD4721F8B19 for ; Wed, 3 Aug 2011 01:34:16 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AugGAHAHOU6T5xpZ/2dsb2JhbABChEeUAo8Sd4FAAQEFI1URCxgJFgsCAgkDAgECAUUTCAEBh2quFZEzhTKBEASNfoR9hQeLXw X-IronPort-AV: E=Sophos;i="4.67,309,1309730400"; d="asc'?scan'208";a="1560504" Received: from freja.fzu.cz ([147.231.26.89]) by serv147.fzu.cz with ESMTP; 03 Aug 2011 10:34:26 +0200 Received: from [192.168.1.250] (unknown [94.230.152.5]) by freja.fzu.cz (Postfix) with ESMTPSA id E1F393DA8C for ; Wed, 3 Aug 2011 10:34:25 +0200 (CEST) Message-ID: <4E390810.7090709@gentoo.org> Date: Wed, 03 Aug 2011 10:34:24 +0200 From: =?UTF-8?B?SmFuIEt1bmRyw6F0?= User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6 MIME-Version: 1.0 To: imap5@ietf.org References: <20110802185031.GA13692@brong.net> <9031.1312316256.119145@puncture> <20110802203913.GA15456@brong.net> <9031.1312318939.365875@puncture> <20110802213442.GA16293@brong.net> <4E38D540.6070600@laposte.net> <20110803062420.GB6947@brong.net> <4E38F3AD.5030501@laposte.net> <4E39069C.6060409@laposte.net> In-Reply-To: <4E39069C.6060409@laposte.net> X-Enigmail-Version: 1.1.1 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig7BA52B4F9D5E13CA74B86C87" X-Mailman-Approved-At: Thu, 04 Aug 2011 10:37:11 -0700 Subject: Re: [imap5] something to remember in light of recent conversations X-BeenThere: imap5@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion on drastically slimming-down IMAP." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Aug 2011 08:35:51 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig7BA52B4F9D5E13CA74B86C87 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 08/03/11 10:28, Gilles LAMIRAL wrote: > If I had so poor clients as you mean to deal with I certainly=20 > would use 2Tb consumer hard disks. >=20 > May be you know what Google use as hard disks?=20 > The poor consumer ones. Really. Follow them, > they do know why they've done that choice, technically > and commercially speaking. You're right that quite a few of the massive storage systems available these days run on 7200 RPM SATA drives, and that some storage vendors are happy to use the desktop-grade disks in them. What Bron was saying, though, is that the total cost of a storage system is not only the price of the disk drives, but instead has to include quote a lot of other expenditures, both in HW cost, as well as in power/space consumption and maintenance. There's no doubt that the "storage is cheap" mantra is true. What is also true is that the data deduplication business is pretty flourishing (at least that's what the array vendors tell you), so I guess the problem of limited capacity is very real for most enterprises. Dismissing that with "just buy a 2TB disk drive, man" is not really helpf= ul. Cheers, Jan --=20 Trojita, a fast e-mail client -- http://trojita.flaska.net/ --------------enig7BA52B4F9D5E13CA74B86C87 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk45CBAACgkQamXfqERyJRf6MACgi1NW29RsAJo0UHliMDYpdOxs kWEAnAgL/Q2VH8aWTwn4Por0++x77mOU =PQo8 -----END PGP SIGNATURE----- --------------enig7BA52B4F9D5E13CA74B86C87--