From dcrocker@gmail.com Thu May 10 08:57:31 2012 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 9E86921F8557 for ; Thu, 10 May 2012 08:57:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.567 X-Spam-Level: X-Spam-Status: No, score=-3.567 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8kL1BcjAt00A for ; Thu, 10 May 2012 08:57:31 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 5DE5921F845D for ; Thu, 10 May 2012 08:57:14 -0700 (PDT) Received: by pbcwy7 with SMTP id wy7so2183547pbc.31 for ; Thu, 10 May 2012 08:57:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=ZqAdMQXAHxsKwloISORIcSQnKmp5QjfaReaG/CzW60E=; b=RwqcOPBfqOvw6kJtKbrI6j3mBxfNCQ+pDHyJiz/+w881MQI2uh+ph/ji4oHwsMiOOf faYaVqRWtibFhbBrXuuWoM4UZhI+N9Yx0KdjMYQ6CJV2abHSAlHfVz/6lY1x40LEo9uK ftJQ3VoiShNt5zGnwH14gROao2jjBHo/UlJDKujKEjLzg5mpaGwhI7gXU2kCbN0AksEl r0mPl4Y6D0zCN4AYnX4eJ2poVPzEUxZW0fk3i3tnmKEJXxiF07GTqeA8cMrijTHRTMSp LMkYp8iDftP397Mi6DSRTcsIkmUdPzWSABXRSCaUTHvWF/Z0UWToCOJbWdFzxh/qUPWg ZNqw== Received: by 10.68.211.227 with SMTP id nf3mr11801158pbc.5.1336665434145; Thu, 10 May 2012 08:57:14 -0700 (PDT) Received: from [192.168.1.11] (adsl-67-127-58-62.dsl.pltn13.pacbell.net. [67.127.58.62]) by mx.google.com with ESMTPS id py5sm9897766pbb.1.2012.05.10.08.57.11 (version=SSLv3 cipher=OTHER); Thu, 10 May 2012 08:57:12 -0700 (PDT) Message-ID: <4FABE552.5010304@gmail.com> Date: Thu, 10 May 2012 08:57:06 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Tony Finch References: <833EE8EEE88E4ADE5CDDDADB@caldav.corp.apple.com> <4F3835A1.7060804@qbik.com> <4F397212.1030107@qbik.com> <20120213210805.GB13029@launde.brong.net> <1329315552.1444.140661036879893@webmail.messagingengine.com> <4F3BBFA4.8010107@isode.com> <1329316981.8310.140661036883625@webmail.messagingengine.com> <66F68487BF0EED4BA7D767E2410F30B3EFF259456A@FRSPX100.fr01.awl.atosorigin.net> <20120215211301.GA16253@launde.brong.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Thu, 10 May 2012 09:15:27 -0700 Cc: "Discussion on drastically slimming-down IMAP." Subject: [imap5] Beep 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: Thu, 10 May 2012 15:57:31 -0000 On 2/16/2012 3:30 AM, Tony Finch wrote: > I think BEEP is insane. Masses of complexity just to avoid using multiple > concurrent TCP connections. Having been involved in creating beep, I'm feeling obligated to respond on this. I won't be saying anything that isn't pretty obvious, so the real disparity is almost certainly personal interpretations of degree: Multiple simultaneous TCP connections are highly problematic. Especially for new protocols. The real world of today's Internet makes it difficult to ensure proper operation through firewalls and application gateways. It would be very nice to fix this underlying problem, but until it's fixed, then a new application that uses new TCP ports is not likely to succeed. d/ -- Dave Crocker bbiw.net From fanf2@hermes.cam.ac.uk Thu May 10 09:22:25 2012 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 709F621F852E for ; Thu, 10 May 2012 09:22:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.527 X-Spam-Level: X-Spam-Status: No, score=-6.527 tagged_above=-999 required=5 tests=[AWL=0.072, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jm6gbD4b00Gc for ; Thu, 10 May 2012 09:22:22 -0700 (PDT) Received: from ppsw-50.csi.cam.ac.uk (ppsw-50.csi.cam.ac.uk [131.111.8.150]) by ietfa.amsl.com (Postfix) with ESMTP id A440121F8525 for ; Thu, 10 May 2012 09:22:21 -0700 (PDT) X-Cam-AntiVirus: no malware found X-Cam-SpamDetails: not scanned X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-2.csi.cam.ac.uk ([131.111.8.54]:43436) by ppsw-50.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.157]:25) with esmtpa (EXTERNAL:fanf2) id 1SSW8C-00017b-qL (Exim 4.72) (return-path ); Thu, 10 May 2012 17:22:20 +0100 Received: from fanf2 (helo=localhost) by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1SSW8C-0005fI-6t (Exim 4.67) (return-path ); Thu, 10 May 2012 17:22:20 +0100 Date: Thu, 10 May 2012 17:22:20 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-2.csi.cam.ac.uk To: Dave Crocker In-Reply-To: <4FABE552.5010304@gmail.com> Message-ID: References: <833EE8EEE88E4ADE5CDDDADB@caldav.corp.apple.com> <4F3835A1.7060804@qbik.com> <4F397212.1030107@qbik.com> <20120213210805.GB13029@launde.brong.net> <1329315552.1444.140661036879893@webmail.messagingengine.com> <4F3BBFA4.8010107@isode.com> <1329316981.8310.140661036883625@webmail.messagingengine.com> <66F68487BF0EED4BA7D767E2410F30B3EFF259456A@FRSPX100.fr01.awl.atosorigin.net> <20120215211301.GA16253@launde.brong.net> <4FABE552.5010304@gmail.com> User-Agent: Alpine 2.00 (LSU 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Tony Finch Cc: "Discussion on drastically slimming-down IMAP." Subject: Re: [imap5] Beep 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: Thu, 10 May 2012 16:22:25 -0000 Dave Crocker wrote: > > Multiple simultaneous TCP connections are highly problematic. > Especially for new protocols. > > The real world of today's Internet makes it difficult to ensure proper > operation through firewalls and application gateways. Well they aren't great for congestion control and window sizing, but middleboxes should only be a problem if you are doing FTP-style layering violations. So concurrent connections are normal for HTTP and IMAP and SMTP etc. and work OK for other protocols. After all, the network can't tell the difference between one user's concurrent connections and multiple concurrent users. > It would be very nice to fix this underlying problem, but until it's fixed, > then a new application that uses new TCP ports is not likely to succeed. Everything over port 443. Tony. -- f.anthony.n.finch http://dotat.at/ Malin: Northeast backing north 5 to 7. Moderate or rough. Rain then showers. Moderate or good. From dcrocker@gmail.com Thu May 10 09:31:00 2012 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 EE0A921F86F7 for ; Thu, 10 May 2012 09:31:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.568 X-Spam-Level: X-Spam-Status: No, score=-3.568 tagged_above=-999 required=5 tests=[AWL=0.031, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T27fOUyvk0uc for ; Thu, 10 May 2012 09:31:00 -0700 (PDT) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id 1DA0F21F86E5 for ; Thu, 10 May 2012 09:31:00 -0700 (PDT) Received: by dacx6 with SMTP id x6so2033715dac.31 for ; Thu, 10 May 2012 09:31:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=O0WqIyc63RAmbOvx6A9MU7bApo89eAhCfDclJW4iDIo=; b=hyx0u8XBDkp5TGFI7KgEu6NoIxl4136iLaDEy8EqqcJKMZ/Q/R6MvjPpN/2cJMcOI1 U99tatY2RTpD82TmQxtG6cUXyXYHY+j3iPhVUz8XyykLfEz8FitmC60lbPLOkTaxo55N nTt7xsZ9ZCu6CwnytaxGvnczTn8hevoqcfx29RbnNDIWJ/Th7xJ6QuiXzLSnTGr/G0Od fTojOl5N5zP+LPHytSydcrxGe5stMgp3vY/5oSwQ77C4V2q9GFiSfttiI1KXNQcmZVL0 ivhlmdsVzIDBYyv63HX8hxSP73hRypd9p4W4f/31FLb5/13hmbAvyoqtPKb2UYbon7Gh aImw== Received: by 10.68.226.99 with SMTP id rr3mr21809421pbc.48.1336667459825; Thu, 10 May 2012 09:30:59 -0700 (PDT) Received: from [192.168.1.11] (adsl-67-127-58-62.dsl.pltn13.pacbell.net. [67.127.58.62]) by mx.google.com with ESMTPS id wn3sm9929177pbc.74.2012.05.10.09.30.56 (version=SSLv3 cipher=OTHER); Thu, 10 May 2012 09:30:58 -0700 (PDT) Message-ID: <4FABED3B.8050707@gmail.com> Date: Thu, 10 May 2012 09:30:51 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Tony Finch References: <833EE8EEE88E4ADE5CDDDADB@caldav.corp.apple.com> <4F3835A1.7060804@qbik.com> <4F397212.1030107@qbik.com> <20120213210805.GB13029@launde.brong.net> <1329315552.1444.140661036879893@webmail.messagingengine.com> <4F3BBFA4.8010107@isode.com> <1329316981.8310.140661036883625@webmail.messagingengine.com> <66F68487BF0EED4BA7D767E2410F30B3EFF259456A@FRSPX100.fr01.awl.atosorigin.net> <20120215211301.GA16253@launde.brong.net> <4FABE552.5010304@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "Discussion on drastically slimming-down IMAP." Subject: Re: [imap5] Beep 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: Thu, 10 May 2012 16:31:01 -0000 On 5/10/2012 9:22 AM, Tony Finch wrote: > Dave Crocker wrote: >> >> Multiple simultaneous TCP connections are highly problematic. >> Especially for new protocols. >> >> The real world of today's Internet makes it difficult to ensure proper >> operation through firewalls and application gateways. > > Well they aren't great for congestion control and window sizing, but a multiplexing mechanism always has those issues, where the underlying issue is making sure that a problem in one sub-channel does not block the others. multiplexing adds complexity. it's always better to find a workable solution that does not require it. > middleboxes should only be a problem if you are doing FTP-style layering > violations. I don't have a guess about what layering violation you think FTP does... So concurrent connections are normal for HTTP and IMAP and I was careful to say "new" protocols. And I think I was careful to cite use of different port numbers. (I certainly meant to be.) Parallel identical connections for protocols that already punch through firewalls are in a very different position of strength than new protocols. However even these are problematic for gateways. On the average, we don't design for concern about gateways, but the issue still exists. > Everything over port 443. well, that's obviously far better than everything over 80... And while I mean that ironically, there's a kernel of reality to it: Beep was produced in response to the clear trend to put everything over http. Beep is lower cost, by quite a bit. It then adds back some cost with the multiplexing mechanism, of course. But that's why it replicates established multiplexing mechanisms from lower layers. For reference, I'm not lobbying for it's use, here. I don't have an opinion for the IMAPnextgen discussion, but wanted to clarify why beep was a long way from crazy. d/ -- Dave Crocker bbiw.net From brong@fastmail.fm Thu May 10 12:56:53 2012 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 35F2921F86D4 for ; Thu, 10 May 2012 12:56:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uMyz1-F94cQX for ; Thu, 10 May 2012 12:56:52 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) by ietfa.amsl.com (Postfix) with ESMTP id 7FE3321F86CF for ; Thu, 10 May 2012 12:56:52 -0700 (PDT) Received: from compute6.internal (compute6.nyi.mail.srv.osa [10.202.2.46]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id 82AD920A72; Thu, 10 May 2012 15:56:51 -0400 (EDT) Received: from frontend2.nyi.mail.srv.osa ([10.202.2.161]) by compute6.internal (MEProxy); Thu, 10 May 2012 15:56:51 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=fastmail.fm; h= date:from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=mesmtp; bh=lvyS7lkgYqV+N3Hs8ZeLnI84 bl4=; b=T5Z/pSMscDpSiwaOJyDBwxRSiOieWtgEvVoO7P/PTIQ8g8r60ElMnPqT 0GMXfofcRQaI65y4WkinuEi+q5mMbanx8bcWGOslHbta9PinYS5WNqGaWOs5atKf pcOm/uMZbkESYSzMHgjy/N3clAMv0ERgMnBoEasB7S0r68qgnjI= 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=lvyS7lkgYqV+N3Hs8ZeLnI84bl4=; b=g3eVlyKK+ev/6xtIR52amjKpWoa6 2Yixi4Ycp77A7MW+PM+TbpKwLa3nF8rmD4N6Dv8sJFWvIwW5aB2JFPceQiz6fgYL YSt1yXDcLKdpMwD60YBXg8A5zzUhmZ+OoRh7rfox/NSzl6p7aZ5SG3wYD+O6hBJM m6ole2d7NL8ENq4= X-Sasl-enc: BifWNNsTSOzhoji/7TeSoiNWDAPYT5r4LBAUxEKjibEN 1336679811 Received: from localhost (151.20.45.31.customer.cdi.no [31.45.20.151]) by mail.messagingengine.com (Postfix) with ESMTPSA id 4398F482445; Thu, 10 May 2012 15:56:51 -0400 (EDT) Received: by localhost (Postfix, from userid 1000) id CA8317E13AC; Thu, 10 May 2012 21:56:50 +0200 (CEST) Date: Thu, 10 May 2012 21:56:50 +0200 From: Bron Gondwana To: Dave Crocker Message-ID: <20120510195650.GB14576@launde.brong.net> References: <1329315552.1444.140661036879893@webmail.messagingengine.com> <4F3BBFA4.8010107@isode.com> <1329316981.8310.140661036883625@webmail.messagingengine.com> <66F68487BF0EED4BA7D767E2410F30B3EFF259456A@FRSPX100.fr01.awl.atosorigin.net> <20120215211301.GA16253@launde.brong.net> <4FABE552.5010304@gmail.com> <4FABED3B.8050707@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4FABED3B.8050707@gmail.com> Organization: brong.net User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "Discussion on drastically slimming-down IMAP." Subject: Re: [imap5] Beep 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: Thu, 10 May 2012 19:56:53 -0000 On Thu, May 10, 2012 at 09:30:51AM -0700, Dave Crocker wrote: > >Everything over port 443. > > well, that's obviously far better than everything over 80... > > And while I mean that ironically, there's a kernel of reality to it: > Beep was produced in response to the clear trend to put everything > over http. Beep is lower cost, by quite a bit. > > It then adds back some cost with the multiplexing mechanism, of > course. But that's why it replicates established multiplexing > mechanisms from lower layers. > > > For reference, I'm not lobbying for it's use, here. I don't have an > opinion for the IMAPnextgen discussion, but wanted to clarify why > beep was a long way from crazy. SCTP seems like a great idea apart from the difficulty bootstrapping support - you need more than just application-level support. BEEP suffers a bit from the "you need a less-common library to implement it" problem too - but at least libraries seem pretty common. It's hard to argue with everything over 443 from a perspective of "just f'n well works for users" though. Bron. From adrien@qbik.com Thu May 10 16:03:31 2012 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 EBBE921F85A2 for ; Thu, 10 May 2012 16:03:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.768 X-Spam-Level: X-Spam-Status: No, score=-5.768 tagged_above=-999 required=5 tests=[AWL=-4.169, BAYES_00=-2.599, SUBJ_RE_NUM=1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g4PLTAI3oB0z for ; Thu, 10 May 2012 16:03:31 -0700 (PDT) Received: from smtp.qbik.com (smtp.qbik.com [210.55.214.35]) by ietfa.amsl.com (Postfix) with ESMTP id B841421F859F for ; Thu, 10 May 2012 16:03:30 -0700 (PDT) Received: From sago.qbik.com (unverified [192.168.0.3]) by SMTP Server [192.168.0.1] (WinGate SMTP Receiver v7.2.0 (Build 3409)) with SMTP id <0019021447@smtp.qbik.com>; Fri, 11 May 2012 11:03:27 +1200 Received: From [192.168.0.10] (unverified [192.168.0.10]) by SMTP Server [192.168.0.3] (WinGate SMTP Receiver v7.2.0 (Build 3411)) with SMTP id <0010104960@sago.qbik.com>; Fri, 11 May 2012 11:03:26 +1200 From: "Adrien W. de Croy" To: "Dave Crocker" , "Tony Finch" Date: Thu, 10 May 2012 23:03:26 +0000 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; format=flowed; charset=utf-8 In-Reply-To: <4FABED3B.8050707@gmail.com> Message-Id: Mime-Version: 1.0 User-Agent: eM_Client/4.0.14522.0 Cc: "Discussion on drastically slimming-down IMAP." Subject: Re: [imap5] Beep X-BeenThere: imap5@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: "Adrien W. de Croy" List-Id: "Discussion on drastically slimming-down IMAP." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 May 2012 23:03:32 -0000 There was recently a long and heated discussion about the same issue on = the HTTP WG list. I think it's a really bad idea to migrate everything to port 443, and would be a huge step backwards for the internet. Firstly, there are many intermediaries that snoop into port 443 (break into the SSL with spoofed certs etc) and expect to find HTTP in there. = This is done because there's no supported way for an intermediary to perform its necessary functions on https. IN fact we're looking into options to put the intermediary in the picture, since there are many valid bona fide reasons why the content requires inspection (e.g. malware). Especially since more and more of the web is moving to https = (FB, Gmail etc etc). the arguments for such a proposal are things like * 443 gets through firewalls (response - now they may, probably not so in future). * everyone should be encrypting everything anyway (response - not true, = many situations require transparency, and forcing burden of SSL/TLS deployment everywhere is highly problematic) Basically my position is moving to port 443 for other protocols is an escalation in the arms-race between client / server vendors and intermediary vendors. There must be a better way. BEEP may seem insane. It kinda is, but it's doing what it has to given = the limitations. However specifying some new protocol such as IMAP5 to = go over BEEP _would_ be insane. Adrien ------ Original Message ------ From: "Dave Crocker" To: "Tony Finch" Cc: "Discussion on drastically slimming-down IMAP." Sent: 11/05/2012 4:30:51 a.m. Subject: Re: [imap5] Beep > > >On 5/10/2012 9:22 AM, Tony Finch wrote: >>Dave Crocker wrote: >>> >>> Multiple simultaneous TCP connections are highly problematic. >>> Especially for new protocols. >>> >>>The real world of today's Internet makes it difficult to ensure >>>proper >>>operation through firewalls and application gateways. >> >>Well they aren't great for congestion control and window sizing, but > >a multiplexing mechanism always has those issues, where the underlying = >issue is making sure that a problem in one sub-channel does not block >the others. > >multiplexing adds complexity. it's always better to find a workable >solution that does not require it. > > >>middleboxes should only be a problem if you are doing FTP-style >>layering >>violations. > >I don't have a guess about what layering violation you think FTP >does... > > >So concurrent connections are normal for HTTP and IMAP and > >I was careful to say "new" protocols. And I think I was careful to >cite use of different port numbers. (I certainly meant to be.) > >Parallel identical connections for protocols that already punch >through firewalls are in a very different position of strength than >new protocols. However even these are problematic for gateways. On the = >average, we don't design for concern about gateways, but the issue >still exists. > > > >>Everything over port 443. > >well, that's obviously far better than everything over 80... > >And while I mean that ironically, there's a kernel of reality to it: >Beep was produced in response to the clear trend to put everything >over http. Beep is lower cost, by quite a bit. > >It then adds back some cost with the multiplexing mechanism, of >course. But that's why it replicates established multiplexing >mechanisms from lower layers. > > >For reference, I'm not lobbying for it's use, here. I don't have an >opinion for the IMAPnextgen discussion, but wanted to clarify why beep = >was a long way from crazy. > >d/ >-- Dave Crocker > bbiw.net >_______________________________________________ >imap5 mailing list >imap5@ietf.org >https://www.ietf.org/mailman/listinfo/imap5 From adrien@qbik.com Thu May 10 16:08:11 2012 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 7B26B21F855A for ; Thu, 10 May 2012 16:08:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.645 X-Spam-Level: X-Spam-Status: No, score=-5.645 tagged_above=-999 required=5 tests=[AWL=-4.046, BAYES_00=-2.599, SUBJ_RE_NUM=1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1obk8Ug4T8Aw for ; Thu, 10 May 2012 16:08:10 -0700 (PDT) Received: from smtp.qbik.com (smtp.qbik.com [210.55.214.35]) by ietfa.amsl.com (Postfix) with ESMTP id E7C3121F8552 for ; Thu, 10 May 2012 16:08:09 -0700 (PDT) Received: From sago.qbik.com (unverified [192.168.0.3]) by SMTP Server [192.168.0.1] (WinGate SMTP Receiver v7.2.0 (Build 3409)) with SMTP id <0019021458@smtp.qbik.com>; Fri, 11 May 2012 11:08:09 +1200 Received: From [192.168.0.10] (unverified [192.168.0.10]) by SMTP Server [192.168.0.3] (WinGate SMTP Receiver v7.2.0 (Build 3411)) with SMTP id <0010104966@sago.qbik.com>; Fri, 11 May 2012 11:08:08 +1200 From: "Adrien W. de Croy" To: "Adrien W. de Croy" , "Dave Crocker" , "Tony Finch" Date: Thu, 10 May 2012 23:08:08 +0000 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; format=flowed; charset=utf-8 In-Reply-To: Message-Id: Mime-Version: 1.0 User-Agent: eM_Client/4.0.14522.0 Cc: "Discussion on drastically slimming-down IMAP." Subject: Re: [imap5] Beep X-BeenThere: imap5@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: "Adrien W. de Croy" List-Id: "Discussion on drastically slimming-down IMAP." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 May 2012 23:08:11 -0000 =EF=BB=BF ------ Original Message ------ From: "Adrien W. de Croy" To: "Dave Crocker" ;"Tony Finch" Cc: "Discussion on drastically slimming-down IMAP." Sent: 11/05/2012 11:03:26 a.m. Subject: Re: [imap5] Beep > >There was recently a long and heated discussion about the same issue >on the HTTP WG list. > >I think it's a really bad idea to migrate everything to port 443, and >would be a huge step backwards for the internet. > >Firstly, there are many intermediaries that snoop into port 443 (break = >into the SSL with spoofed certs etc) and expect to find HTTP in there. = >This is done because there's no supported way for an intermediary to >perform its necessary functions on https. IN fact we're looking into >options to put the intermediary in the picture, since there are many >valid bona fide reasons why the content requires inspection (e.g. >malware). Especially since more and more of the web is moving to https = >(FB, Gmail etc etc). > >the arguments for such a proposal are things like > >* 443 gets through firewalls (response - now they may, probably not so = >in future). >* everyone should be encrypting everything anyway (response - not >true, many situations require transparency, and forcing burden of >SSL/TLS deployment everywhere is highly problematic) > >Basically my position is moving to port 443 for other protocols is an >escalation in the arms-race between client / server vendors and >intermediary vendors. There must be a better way. > >BEEP may seem insane. It kinda is, but it's doing what it has to given = >the limitations. However specifying some new protocol such as IMAP5 to = >go over BEEP _would_ be insane. actually I'm confusing BEEP with something else (BOSH) ... strike that final comment... I don't know enough about it to comment. Adrien > > >Adrien > > >------ Original Message ------ >From: "Dave Crocker" >To: "Tony Finch" >Cc: "Discussion on drastically slimming-down IMAP." >Sent: 11/05/2012 4:30:51 a.m. >Subject: Re: [imap5] Beep >> >> >>On 5/10/2012 9:22 AM, Tony Finch wrote: >>>Dave Crocker wrote: >>>> >>>> Multiple simultaneous TCP connections are highly problematic. = >>>>Especially for new protocols. >>>>The real world of today's Internet makes it difficult to ensure >>>>proper operation through firewalls and application gateways. >>> >>>Well they aren't great for congestion control and window sizing, but = >> >>a multiplexing mechanism always has those issues, where the >>underlying issue is making sure that a problem in one sub-channel >>does not block the others. >>multiplexing adds complexity. it's always better to find a workable >>solution that does not require it. >> >>>middleboxes should only be a problem if you are doing FTP-style >>>layering violations. >> >>I don't have a guess about what layering violation you think FTP >>does... >> >>So concurrent connections are normal for HTTP and IMAP and >>I was careful to say "new" protocols. And I think I was careful to >>cite use of different port numbers. (I certainly meant to be.) >>Parallel identical connections for protocols that already punch >>through firewalls are in a very different position of strength than >>new protocols. However even these are problematic for gateways. On >>the average, we don't design for concern about gateways, but the >>issue still exists. >> >> >>>Everything over port 443. >> >>well, that's obviously far better than everything over 80... >>And while I mean that ironically, there's a kernel of reality to it: >>Beep was produced in response to the clear trend to put everything >>over http. Beep is lower cost, by quite a bit. >>It then adds back some cost with the multiplexing mechanism, of >>course. But that's why it replicates established multiplexing >>mechanisms from lower layers. >> >>For reference, I'm not lobbying for it's use, here. I don't have an >>opinion for the IMAPnextgen discussion, but wanted to clarify why >>beep was a long way from crazy. >>d/ -- Dave Crocker bbiw.net >>_______________________________________________ imap5 mailing list >>imap5@ietf.org https://www.ietf.org/mailman/listinfo/imap5 > >_______________________________________________ >imap5 mailing list >imap5@ietf.org >https://www.ietf.org/mailman/listinfo/imap5 From barryleiba@gmail.com Wed May 30 06:39:23 2012 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 63F3521F873E for ; Wed, 30 May 2012 06:39:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.964 X-Spam-Level: X-Spam-Status: No, score=-102.964 tagged_above=-999 required=5 tests=[AWL=0.013, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GhjUoIoqLcJb for ; Wed, 30 May 2012 06:39:22 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 23E2321F86DD for ; Wed, 30 May 2012 06:39:19 -0700 (PDT) Received: by obbeh20 with SMTP id eh20so796116obb.31 for ; Wed, 30 May 2012 06:39:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:content-type; bh=qwWe+djAqjX/Nt6A+AeUVPq4VhcSe6CotNM2snJqnwA=; b=pMfsMwY37RsQekDU26E/ozoak+s8DvC9EmFdNE16UrpPy4YR1auJXbEwKk2LJOUEL8 OMQy2XXMy0qNJEg1KO/txiuD+vRlB1QduShHcMgD2jeH+YGHIFEyoNczI8G2s8+2VdRE qyonVKDUAFIEaSY/iXUKiBnUKBI63tGUv2hSVGUfVS+MN59Ds5CcoUq59szck4gUuv2/ Vp8aiUxoC3rO/KLYaiTsFSXfKJv2QxRn06M1c8q13QchwdagJOQNCqrZ63zjATTmw/xE p/rKj6h8c6weWBHKXfHOGKoxA6BzMzw9sPcpshmfCExrwAubvL/zEvFLhp/mJmsBvhh/ FJJA== MIME-Version: 1.0 Received: by 10.182.18.137 with SMTP id w9mr9399433obd.75.1338385158615; Wed, 30 May 2012 06:39:18 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.60.21.35 with HTTP; Wed, 30 May 2012 06:39:18 -0700 (PDT) Date: Wed, 30 May 2012 09:39:18 -0400 X-Google-Sender-Auth: sMrA56XjBf9xC8foNu3OAcaBWfs Message-ID: From: Barry Leiba To: imap5@ietf.org Content-Type: multipart/mixed; boundary=f46d043bdf32f3b2de04c141130e Subject: [imap5] Proposal for "imapmove" working group 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, 30 May 2012 13:39:23 -0000 --f46d043bdf32f3b2de04c141130e Content-Type: text/plain; charset=ISO-8859-1 At the instigation of some proponents, I am bringing the attached working group charter proposal to the IESG. Short version: the proposal is to develop a Proposed Standard for an IMAP MOVE protocol extension, which will most likely support only UID MOVE, and to do it on a very short schedule. An initial proposal for such a protocol is here: http://datatracker.ietf.org/doc/draft-gulbrandsen-imap-move/ ...and that's a likely starting point for the working group. Again: a very short schedule. We have a good starting proposal and a fairly simple task (but see below), along with several implementations that are asking for this. The discussion and progress will be tightly managed. Note that this proposal comes with some controversy -- mostly, but not entirely, based on opinions that it's not really needed nor necessary, and that it's not as easy to get it right as some think. See the (long) thread of discussion from the imap-protocol mailing list that starts here: http://mailman2.u.washington.edu/pipermail/imap-protocol/2010-June/001088.html Comments on the charter proposal are welcome, and should be posted to this list, (and no need to CC me). The charter will be on the 7 June IESG telechat for initial review, and will be back on 21 June for possible approval. Barry Leiba, Applications AD --f46d043bdf32f3b2de04c141130e Content-Type: text/plain; charset=US-ASCII; name="charter-ietf-imapmove-00-00.txt" Content-Disposition: attachment; filename="charter-ietf-imapmove-00-00.txt" Content-Transfer-Encoding: base64 X-Attachment-Id: f_h2ufnmg80 SU1BUCBNT1ZFIGV4dGVuc2lvbiAoaW1hcG1vdmUpCgpDaGFpcihzKTogVEJEIAoKQXBwbGljYXRp b25zIEFyZWEgRGlyZWN0b3Iocyk6CiAgUGV0ZSBSZXNuaWNrIDxwcmVzbmlja0BxdWFsY29tbS5j b20+IAogIEJhcnJ5IExlaWJhIDxiYXJyeWxlaWJhQGNvbXB1dGVyLm9yZz4gCgpNYWlsaW5nIExp c3RzOgogIEdlbmVyYWwgRGlzY3Vzc2lvbjogaW1hcGV4dEBpZXRmLm9yZwogIFRvIFN1YnNjcmli ZTogICAgICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pbWFwNQogIEFy Y2hpdmU6ICAgICAgICAgICAgaHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL2lt YXA1LwogCkRlc2NyaXB0aW9uIG9mIFdvcmtpbmcgR3JvdXA6CgpUaGUgSW50ZXJuZXQgTWVzc2Fn ZSBBY2Nlc3MgUHJvdG9jb2wgKElNQVApLCBkZWZpbmVkIGluIFJGQyAzNTAxLApzcGVjaWZpZXMg YSBwcm90b2NvbCBmb3IgdHJhbnNmZXJyaW5nIGVtYWlsIG1lc3NhZ2VzIGJldHdlZW4gYSBzZXJ2 ZXIKdGhhdCBpbXBsZW1lbnRzIGEgbWVzc2FnZSBzdG9yZSwgYW5kIGEgY2xpZW50LiAgSXQgYWxz byBpbmNsdWRlcwpjb21tYW5kcyBmb3IgbWFuaXB1bGF0aW5nIHRoZSBtZXNzYWdlIHN0b3JlIC0t IGNyZWF0aW5nLCBkZWxldGluZywgYW5kCnJlbmFtaW5nIG1haWxib3hlcywgYWRkaW5nIGEgbWVz c2FnZSB0byBhIG1haWxib3gsIGFuZCBjb3B5aW5nCm1lc3NhZ2VzIGZyb20gb25lIG1haWxib3gg dG8gYW5vdGhlci4KCkl0J3Mgb2Z0ZW4gdGhlIGNhc2UgdGhhdCBhbiBJTUFQIGNsaWVudCBuZWVk cyB0byBtb3ZlIChub3QgY29weSkKbWVzc2FnZXMgZnJvbSBvbmUgbWFpbGJveCB0byBhbm90aGVy LiAgVGhlIG1lY2hhbmlzbSB0aGF0IElNQVAKcHJvdmlkZXMgdG8gZG8gdGhhdCBpcyBhIG11bHRp LXN0ZXAgcHJvY2VzczoKMS4gQ29weSB0aGUgbWVzc2FnZXMgZnJvbSB0aGUgc291cmNlIG1haWxi b3ggdG8gdGhlIHRhcmdldCBtYWlsYm94LgoyLiBGbGFnIHRoZSBvcmlnaW5hbCBtZXNzYWdlcyBp biB0aGUgc291cmNlIG1haWxib3ggYXMgZGVsZXRlZC4KMy4gRXhwdW5nZSB0aGUgZGVsZXRlZCBt ZXNzYWdlcyBmcm9tIHRoZSBzb3VyY2UgbWFpbGJveC4KCkltcGxlbWVudG9ycyBoYXZlIGxvbmcg cG9pbnRlZCBvdXQgc29tZSBzaG9ydGNvbWluZ3Mgd2l0aCB0aGlzCmFwcHJvYWNoLiAgQmVjYXVz ZSB0aGUgbW92aW5nIG9mIGEgbWVzc2FnZSBpcyBub3QgYW4gYXRvbWljIHByb2Nlc3MsCmludGVy cnVwdGlvbnMgY2FuIGxlYXZlIG1lc3NhZ2VzIGluIGludGVybWVkaWF0ZSBzdGF0ZXMuICBCZWNh dXNlCm11bHRpcGxlIGNsaWVudHMgY2FuIGJlIGFjY2Vzc2luZyB0aGUgbWFpbGJveGVzIGF0IHRo ZSBzYW1lIHRpbWUsCmNsaWVudHMgY2FuIHNlZSBtZXNzYWdlcyBpbiBpbnRlcm1lZGlhdGUgc3Rh dGVzIGV2ZW4gd2l0aG91dAppbnRlcnJ1cHRpb25zLiAgSWYgdGhlIHNvdXJjZSBtYWlsYm94IGNv bnRhaW5zIG90aGVyIG1lc3NhZ2VzIHRoYXQgYXJlCmZsYWdnZWQgZm9yIGRlbGV0aW9uLCB0aGUg dGhpcmQgc3RlcCBoYXMgdGhlIHNpZGUgZWZmZWN0IG9mIGV4cHVuZ2luZwptb3JlIHRoYW4ganVz dCB0aGUgc2V0IG9mIG1vdmVkIG1lc3NhZ2VzLiAgQW5kIHNlcnZlcnMgd2l0aCBjZXJ0YWluCnR5 cGVzIG9mIGJhY2stZW5kIG1lc3NhZ2Ugc3RvcmVzIG1pZ2h0IGhhdmUgZWZmaWNpZW50IHdheXMg b2YgbW92aW5nCm1lc3NhZ2VzLCB3aGljaCBkb24ndCBpbnZvbHZlIGFjdHVhbCBjb3B5aW5nIG9m IGRhdGEuICBTdWNoCmVmZmljaWVuY2llcyBhcmUgb2Z0ZW4gbm90IGF2YWlsYWJsZSB0byB0aGUg Y29weS9mbGFnL2V4cHVuZ2UgcHJvY2Vzcy4KClRoZSBJTUFQIE1PVkUgZXh0ZW5zaW9uIChpbWFw bW92ZSkgd29ya2luZyBncm91cCBoYXMgdGhlIHNpbmdsZSB0YXNrCm9mIGRldmVsb3BpbmcgYW4g YXRvbWljIElNQVAgTU9WRSBjb21tYW5kIHRoYXQgd2lsbCBtb3ZlIGEgc2V0IG9mCm1lc3NhZ2Vz IGZyb20gYSBzb3VyY2UgbWFpbGJveCB0byBhIHRhcmdldCBtYWlsYm94IGluIGEgc2luZ2xlCm9w ZXJhdGlvbi4gIFRoZSBncm91cCB3aWxsIHVzZSBkcmFmdC1ndWxicmFuZHNlbi1pbWFwLW1vdmUg YXMgYQpzdGFydGluZyBwb2ludCwgYW5kIHdpbGwgcHJvZHVjZSBhIFN0YW5kYXJkcyBUcmFjayBk b2N1bWVudC4KCkFzIHBhcnQgb2YgdGhlIHByb3RvY29sIGRldmVsb3BtZW50LCBpbXBsZW1lbnRh dGlvbiBleHBlcmllbmNlIG9uIGJvdGgKdGhlIGNsaWVudCBhbmQgc2VydmVyIHNpZGUgaXMgaGln aGx5IGRlc2lyZWFibGUsIHNvIHRoYXQgdGhlIGFjdHVhbApvcGVyYXRpb25hbCB2YWx1ZSBvZiB0 aGlzIGV4dGVuc2lvbiBjYW4gYmUgYXNzZXNzZWQuIFRoZSB3b3JraW5nIGdyb3VwCndpbGwgZG9j dW1lbnQgdGhlIHJlc3VsdHMgb2YgdGhpcyBleHBlcmllbmNlIG9uIHRoZSB3b3JraW5nIGdyb3Vw Cndpa2kuCgpObyBvdGhlciBJTUFQIGV4dGVuc2lvbiB3b3JrIGlzIGluIHNjb3BlIGZvciB0aGlz IHdvcmtpbmcgZ3JvdXAuCgpNaWxlc3RvbmVzCgowNy8yMDEyICAgIEluaXRpYWwgYWRvcHRpb24g b2YgSU1BUCBNT1ZFIHByb3RvY29sIGRvY3VtZW50CjA3LzIwMTIgICAgRXN0YWJsaXNobWVudCBv ZiBpbXBsZW1lbnRhdGlvbiB0cmFja2luZyBvbiB0aGUgd29ya2luZwogICAgICAgICAgIGdyb3Vw IHdpa2kKMDgvMjAxMiAgICBJbml0aWFsIGFzc2Vzc21lbnQgb2YgaW1wbGVtZW50YXRpb24gcmVz dWx0cwowOS8yMDEyICAgIEZpbmFsIHJlcG9ydCBvbiBpbXBsZW1lbnRhdGlvbiByZXN1bHRzCjEw LzIwMTIgICAgSU1BUCBNT1ZFIHByb3RvY29sIGRvY3VtZW50IHRvIElFU0cgYXMgUHJvcG9zZWQg U3RhbmRhcmQK --f46d043bdf32f3b2de04c141130e-- From tss@iki.fi Wed May 30 07:20:18 2012 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 B138E21F8685 for ; Wed, 30 May 2012 07:20:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.561 X-Spam-Level: X-Spam-Status: No, score=-109.561 tagged_above=-999 required=5 tests=[AWL=1.038, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gk96JEu4xGLm for ; Wed, 30 May 2012 07:20:18 -0700 (PDT) Received: from dovecot.org (dovecot.org [193.210.130.67]) by ietfa.amsl.com (Postfix) with ESMTP id 6B30921F8616 for ; Wed, 30 May 2012 07:20:17 -0700 (PDT) Received: from [192.168.10.101] (a88-112-255-76.elisa-laajakaista.fi [88.112.255.76]) by dovecot.org (Postfix) with ESMTP id CA5AB1AE876B for ; Wed, 30 May 2012 17:20:15 +0300 (EEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1084) From: Timo Sirainen In-Reply-To: Date: Wed, 30 May 2012 17:20:15 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: "Discussion on drastically slimming-down IMAP." X-Mailer: Apple Mail (2.1084) Subject: Re: [imap5] Proposal for "imapmove" working group 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, 30 May 2012 14:20:18 -0000 On 30.5.2012, at 16.39, Barry Leiba wrote: > Comments on the charter proposal are welcome, and should be posted to > this list, (and no need to CC me). The charter will > be on the 7 June IESG telechat for initial review, and will be back on > 21 June for possible approval. I like how UID MOVE is defined to be a combination of UID = COPY+STORE+EXPUNGE commands. That's why I think the word "atomic" should = be removed from everywhere. The command is useful even if it's not = strictly atomic, just as long as it normally looks that way to clients. From cyrus@daboo.name Wed May 30 07:40:03 2012 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 346D721F8691 for ; Wed, 30 May 2012 07:40:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1e+gEa4tWnrB for ; Wed, 30 May 2012 07:40:02 -0700 (PDT) Received: from daboo.name (daboo.name [173.13.55.49]) by ietfa.amsl.com (Postfix) with ESMTP id 8461821F8687 for ; Wed, 30 May 2012 07:40:02 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by daboo.name (Postfix) with ESMTP id F02E82831D3A; Wed, 30 May 2012 10:40:01 -0400 (EDT) X-Virus-Scanned: amavisd-new at daboo.name Received: from daboo.name ([127.0.0.1]) by localhost (daboo.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4kCEHi6E1Kco; Wed, 30 May 2012 10:39:56 -0400 (EDT) Received: from caldav.corp.apple.com (unknown [17.45.162.46]) by daboo.name (Postfix) with ESMTPSA id 6B03C2831D26; Wed, 30 May 2012 10:39:55 -0400 (EDT) Date: Wed, 30 May 2012 10:39:51 -0400 From: Cyrus Daboo To: Barry Leiba , imap5@ietf.org Message-ID: In-Reply-To: References: X-Mailer: Mulberry/4.1.0a3 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline; size=1615 Subject: Re: [imap5] Proposal for "imapmove" working group 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, 30 May 2012 14:40:03 -0000 Hi Barry, --On May 30, 2012 9:39:18 AM -0400 Barry Leiba wrote: > At the instigation of some proponents, I am bringing the attached > working group charter proposal to the IESG. Short version: the > proposal is to develop a Proposed Standard for an IMAP MOVE protocol > extension, which will most likely support only UID MOVE, and to do it > on a very short schedule. An initial proposal for such a protocol is > here: > http://datatracker.ietf.org/doc/draft-gulbrandsen-imap-move/ > ...and that's a likely starting point for the working group. > > Again: a very short schedule. We have a good starting proposal and a > fairly simple task (but see below), along with several implementations > that are asking for this. The discussion and progress will be tightly > managed. I seriously question the need to spin up a working group just for this one proposal. I realize that there is significant controversy over the need for this extension, but having a working group won't change that fact. In my opinion this should be handled as an individual submission but with an "experienced" shepherd "appointed" by the Apps ADs to manage the development and consensus of this proposal - perhaps on a dedicated mailing list, but maybe reusing imapext or some other suitable list. I would rather not waste time looking over a charter and milestones and all the rest of the WG setup overhead when there is just one document to deal with. In any case, I am willing to volunteer to chair or be the shepherd as I think this extension is important and long overdue. -- Cyrus Daboo From alexey.melnikov@isode.com Wed May 30 07:45:52 2012 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 DCB3111E80C0 for ; Wed, 30 May 2012 07:45:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.511 X-Spam-Level: X-Spam-Status: No, score=-102.511 tagged_above=-999 required=5 tests=[AWL=0.088, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 19jhbXlw2Bv1 for ; Wed, 30 May 2012 07:45:50 -0700 (PDT) Received: from rufus.isode.com (cl-125.lon-03.gb.sixxs.net [IPv6:2a00:14f0:e000:7c::2]) by ietfa.amsl.com (Postfix) with ESMTP id 8C57211E80B6 for ; Wed, 30 May 2012 07:45:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1338389148; d=isode.com; s=selector; i=@isode.com; bh=oDbXxnPvF8PSZgqWQKxi7XuUveAH31dVR1+AOyLnJzI=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=WhrEcJOy3JLn4nHuVYMF2GlW7FT/MNsnA8RHlLPseMmDz2dtYLbE/0xevgGpmKRI20C1CN f4OFSJ32SyXxSGjBEY5LR6H05hbDdeNudwwv9CJBAJ4iaom6m+FcBXb5XMC77rlFFN34e0 0ZzdRLpnoNJBdRW94LCzdduRciZKRdQ=; Received: from [172.16.1.29] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPSA id ; Wed, 30 May 2012 15:45:48 +0100 X-SMTP-Protocol-Errors: PIPELINING Message-ID: <4FC63299.8090800@isode.com> Date: Wed, 30 May 2012 15:45:45 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 To: Cyrus Daboo References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Barry Leiba , imap5@ietf.org Subject: Re: [imap5] Proposal for "imapmove" working group 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, 30 May 2012 14:45:52 -0000 On 30/05/2012 15:39, Cyrus Daboo wrote: > Hi Barry, > > --On May 30, 2012 9:39:18 AM -0400 Barry Leiba > wrote: > >> At the instigation of some proponents, I am bringing the attached >> working group charter proposal to the IESG. Short version: the >> proposal is to develop a Proposed Standard for an IMAP MOVE protocol >> extension, which will most likely support only UID MOVE, and to do it >> on a very short schedule. An initial proposal for such a protocol is >> here: >> http://datatracker.ietf.org/doc/draft-gulbrandsen-imap-move/ >> ...and that's a likely starting point for the working group. >> >> Again: a very short schedule. We have a good starting proposal and a >> fairly simple task (but see below), along with several implementations >> that are asking for this. The discussion and progress will be tightly >> managed. > > I seriously question the need to spin up a working group just for this > one proposal. I realize that there is significant controversy over the > need for this extension, but having a working group won't change that > fact. > > In my opinion this should be handled as an individual submission but > with an "experienced" shepherd "appointed" by the Apps ADs to manage > the development and consensus of this proposal Cyrus, there was a private round of discussion with ADs and they indicated that they are not willing to process this document as AD sponsored (rightly so in this case). > - perhaps on a dedicated mailing list, but maybe reusing imapext or > some other suitable list. I would rather not waste time looking over a > charter and milestones and all the rest of the WG setup overhead when > there is just one document to deal with. > > In any case, I am willing to volunteer to chair or be the shepherd as > I think this extension is important and long overdue. > From barryleiba@gmail.com Wed May 30 07:46:08 2012 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 714C611E80B6 for ; Wed, 30 May 2012 07:46:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.966 X-Spam-Level: X-Spam-Status: No, score=-102.966 tagged_above=-999 required=5 tests=[AWL=0.011, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HZpeYq6fipvH for ; Wed, 30 May 2012 07:46:06 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id AAC2111E80CD for ; Wed, 30 May 2012 07:45:59 -0700 (PDT) Received: by obbeh20 with SMTP id eh20so878331obb.31 for ; Wed, 30 May 2012 07:45:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type; bh=lKMdQcgZ0W0UBtsgl3Pucy18tfP/EU/5SIaXoQ6X5gc=; b=jp/27ezNjuTKbyy25OvL3SIpUXKURPp3Jn1JsJ3xIzReVJ4MgynqK7dQcWIR9j+kAZ bPxtLEZIgJCm/qe4K7khLPymklOoBlhq8swdSqM71B8g5ut6UxUADrrhOqiCV1rMNlLj qcVwaMCBAgIfz5Ucbl5aJ/ntx247qfLjEVcFtWQ9afpFcS5LbFRrEytpxPxbrD+X9mYF eTYQJdwS0yuJNVvQVWs8dlCn0i0eLDYh2oLzTHPy173mqexMfme9n6kpbaQwagibQWAG xvJUzlpve2U8eIXskxMhuLyFwyKGOkfzcwGMnOCWi1JokHohEbW/vawtlR+zg90yEPz1 vfEw== MIME-Version: 1.0 Received: by 10.182.45.72 with SMTP id k8mr15544410obm.51.1338389158621; Wed, 30 May 2012 07:45:58 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.60.21.35 with HTTP; Wed, 30 May 2012 07:45:58 -0700 (PDT) In-Reply-To: References: Date: Wed, 30 May 2012 10:45:58 -0400 X-Google-Sender-Auth: WtKokXx3ndFm2TOvGS7JoNRJWYA Message-ID: From: Barry Leiba To: imap5@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [imap5] Proposal for "imapmove" working group 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, 30 May 2012 14:46:10 -0000 Cyrus says... > I seriously question the need to spin up a working group just for this one > proposal. I realize that there is significant controversy over the need for > this extension, but having a working group won't change that fact. Well, the IESG discussed this informally, and decided that a working group is the best approach. At some level, we ought never need a working group for most things: WEIRDS, REPUTE, OAUTH, ALTO.... This one is being done in the manner that the RAI area has been handling many of its working groups: short-lived, focused groups, and many of them. You'll note that the total time between the message I posted this morning and the chartering of the working group is likely to be three weeks. That's not a lot of difficulty involved with spinning up a working group. Barry From cyrus@daboo.name Wed May 30 08:39:22 2012 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 76BB011E8087 for ; Wed, 30 May 2012 08:39:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b7yzi0hHbI1F for ; Wed, 30 May 2012 08:39:20 -0700 (PDT) Received: from daboo.name (daboo.name [173.13.55.49]) by ietfa.amsl.com (Postfix) with ESMTP id 5536611E8080 for ; Wed, 30 May 2012 08:39:20 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by daboo.name (Postfix) with ESMTP id A64B62832912; Wed, 30 May 2012 11:39:19 -0400 (EDT) X-Virus-Scanned: amavisd-new at daboo.name Received: from daboo.name ([127.0.0.1]) by localhost (daboo.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vHOIkKCRfsez; Wed, 30 May 2012 11:39:17 -0400 (EDT) Received: from caldav.corp.apple.com (unknown [17.45.162.46]) by daboo.name (Postfix) with ESMTPSA id 5F80C2832907; Wed, 30 May 2012 11:39:16 -0400 (EDT) Date: Wed, 30 May 2012 11:39:13 -0400 From: Cyrus Daboo To: Barry Leiba , imap5@ietf.org Message-ID: <980EDB59DA0A5B134442489A@caldav.corp.apple.com> In-Reply-To: References: X-Mailer: Mulberry/4.1.0a3 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline; size=1058 Subject: Re: [imap5] Proposal for "imapmove" working group 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, 30 May 2012 15:39:22 -0000 Hi Barry, --On May 30, 2012 10:45:58 AM -0400 Barry Leiba wrote: >> I seriously question the need to spin up a working group just for this >> one proposal. I realize that there is significant controversy over the >> need for this extension, but having a working group won't change that >> fact. > > Well, the IESG discussed this informally, and decided that a working > group is the best approach. At some level, we ought never need a > working group for most things: WEIRDS, REPUTE, OAUTH, ALTO.... > > This one is being done in the manner that the RAI area has been > handling many of its working groups: short-lived, focused groups, and > many of them. You'll note that the total time between the message I > posted this morning and the chartering of the working group is likely > to be three weeks. That's not a lot of difficulty involved with > spinning up a working group. Well, OK. If that seems to be what the IESG wants to do, then fine. In that case I will move on to commenting on the charter... -- Cyrus Daboo From cyrus@daboo.name Wed May 30 09:22:18 2012 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 BD64D11E8086 for ; Wed, 30 May 2012 09:22:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B-G-IZ+SQESh for ; Wed, 30 May 2012 09:22:18 -0700 (PDT) Received: from daboo.name (daboo.name [173.13.55.49]) by ietfa.amsl.com (Postfix) with ESMTP id B9BC721F85B9 for ; Wed, 30 May 2012 09:22:16 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by daboo.name (Postfix) with ESMTP id 4551B2833281; Wed, 30 May 2012 12:22:16 -0400 (EDT) X-Virus-Scanned: amavisd-new at daboo.name Received: from daboo.name ([127.0.0.1]) by localhost (daboo.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qL3UEDBEmBGH; Wed, 30 May 2012 12:22:13 -0400 (EDT) Received: from caldav.corp.apple.com (unknown [17.45.162.46]) by daboo.name (Postfix) with ESMTPSA id EFC592833274; Wed, 30 May 2012 12:22:12 -0400 (EDT) Date: Wed, 30 May 2012 12:22:09 -0400 From: Cyrus Daboo To: Barry Leiba , imap5@ietf.org Message-ID: <798B43D6C44C87BB95E00D91@caldav.corp.apple.com> In-Reply-To: References: X-Mailer: Mulberry/4.1.0a3 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline; size=2962 Subject: Re: [imap5] Proposal for "imapmove" working group 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, 30 May 2012 16:22:19 -0000 Hi Barry, Comments on charter below. --On May 30, 2012 9:39:18 AM -0400 Barry Leiba wrote: > Mailing Lists: > General Discussion: imapext@ietf.org > To Subscribe: https://www.ietf.org/mailman/listinfo/imap5 > Archive: http://www.ietf.org/mail-archive/web/imap5/ Which mailing list? imapext or imap5? > It's often the case that an IMAP client needs to move (not copy) > messages from one mailbox to another. The mechanism that IMAP > provides to do that is a multi-step process: > 1. Copy the messages from the source mailbox to the target mailbox. > 2. Flag the original messages in the source mailbox as deleted. > 3. Expunge the deleted messages from the source mailbox. > > Implementors have long pointed out some shortcomings with this > approach. Because the moving of a message is not an atomic process, > interruptions can leave messages in intermediate states. Because > multiple clients can be accessing the mailboxes at the same time, > clients can see messages in intermediate states even without > interruptions. If the source mailbox contains other messages that are > flagged for deletion, the third step has the side effect of expunging ^^^ Really it is "can have the side effect" since clients might have the option of using UID EXPUNGE, or could play tricks of undeleting the non-copied deleted messages, doing the expunge, then re-deleting - of course no one in their right mind would do that... > more than just the set of moved messages. And servers with certain > types of back-end message stores might have efficient ways of moving > messages, which don't involve actual copying of data. Such > efficiencies are often not available to the copy/flag/expunge process. > The IMAP MOVE extension (imapmove) working group has the single task > of developing an atomic IMAP MOVE command that will move a set of ^^^^^^ ^^^^^^^ Use "extension" instead of "command" as the actual command is "UID MOVE" as per Arnt's spec. As per Timo, I am not sure we should state it will be "atomic" as that may restrict what we do in the spec. > messages from a source mailbox to a target mailbox in a single > operation. The group will use draft-gulbrandsen-imap-move as a > starting point, and will produce a Standards Track document. > As part of the protocol development, implementation experience on both > the client and server side is highly desireable, so that the actual > operational value of this extension can be assessed. The working group > will document the results of this experience on the working group > wiki. Are there existing client and server implementations of the draft-gulbrandsen-imap-move right now? Does "implementation" also cover actual interoperability testing, or does it only speak to the actual ability to modify existing servers/clients to adopt the extension? -- Cyrus Daboo From cyrus@daboo.name Wed May 30 09:32:24 2012 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 F184511E808D for ; Wed, 30 May 2012 09:32:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p3zRnGKRA00V for ; Wed, 30 May 2012 09:32:23 -0700 (PDT) Received: from daboo.name (daboo.name [173.13.55.49]) by ietfa.amsl.com (Postfix) with ESMTP id 1636011E8073 for ; Wed, 30 May 2012 09:32:23 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by daboo.name (Postfix) with ESMTP id A988A2833406; Wed, 30 May 2012 12:32:22 -0400 (EDT) X-Virus-Scanned: amavisd-new at daboo.name Received: from daboo.name ([127.0.0.1]) by localhost (daboo.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q8uR80iEmbgB; Wed, 30 May 2012 12:32:21 -0400 (EDT) Received: from caldav.corp.apple.com (unknown [17.45.162.46]) by daboo.name (Postfix) with ESMTPSA id 39B1C28333F9; Wed, 30 May 2012 12:32:21 -0400 (EDT) Date: Wed, 30 May 2012 12:32:18 -0400 From: Cyrus Daboo To: Barry Leiba , imap5@ietf.org Message-ID: <80B7EFD4702B27656A11C377@caldav.corp.apple.com> In-Reply-To: <798B43D6C44C87BB95E00D91@caldav.corp.apple.com> References: <798B43D6C44C87BB95E00D91@caldav.corp.apple.com> X-Mailer: Mulberry/4.1.0a3 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline; size=705 Subject: Re: [imap5] Proposal for "imapmove" working group 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, 30 May 2012 16:32:24 -0000 Hi Barry, imap5@ietf.org, --On May 30, 2012 12:22:09 PM -0400 Cyrus Daboo wrote: >> The IMAP MOVE extension (imapmove) working group has the single task >> of developing an atomic IMAP MOVE command that will move a set of > > ^^^^^^ ^^^^^^^ > > Use "extension" instead of "command" as the actual command is "UID MOVE" > as per Arnt's spec. As per Timo, I am not sure we should state it will be > "atomic" as that may restrict what we do in the spec. Thinking some more, perhaps better text would be: ... developing an IMAP MOVE extension that defines a single command to move a set of ... i.e., "single command" rather than "atomic". -- Cyrus Daboo From brong@fastmail.fm Wed May 30 09:45:37 2012 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 2F46311E80AE for ; Wed, 30 May 2012 09:45:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.999 X-Spam-Level: X-Spam-Status: No, score=-2.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_47=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hMvwoncSe4Zv for ; Wed, 30 May 2012 09:45:36 -0700 (PDT) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) by ietfa.amsl.com (Postfix) with ESMTP id 1CBDB11E80A1 for ; Wed, 30 May 2012 09:45:36 -0700 (PDT) Received: from compute6.internal (compute6.nyi.mail.srv.osa [10.202.2.46]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id 4DB72211C4; Wed, 30 May 2012 12:45:35 -0400 (EDT) Received: from frontend1.nyi.mail.srv.osa ([10.202.2.160]) by compute6.internal (MEProxy); Wed, 30 May 2012 12:45:35 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=fastmail.fm; h= date:from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=mesmtp; bh=7a58rrfs2BwNvUFn4DlWK6Kb LHI=; b=ATqvd/RElHv/vNy7YboLm3583RIUwoLfz1Bol5IYq9C/5NgD09SOvFm4 Xk+IpJr3VGmj9mWIcIT/v0STKgQzLqvilBL9FnzbGQ4M26+qywc67FzKRqzyTB5Q oGWyDU0s2f6Twh5AmNl0POX8uzmr8ZBrnEmkYXeQQ7e06KtzKwc= 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=7a58rrfs2BwNvUFn4DlWK6KbLHI=; b=KLv9Y33jfSzWJgoLe3UnA832bjHS x4HKcZxtGYf6r1svLrAnXJStgCJrDM0Hj4RNHQOiZKuWwk0G1uf/3vBwXxZSdeBK aMITpNd2EHDqxu/PMvvCPOhYbhI4Ua180UWpxgIGpf/cyxVTN/FlKzjqazY4rkcT T+LHphbk4D8ZFdI= X-Sasl-enc: KILZmw+F5ntdjv3R/RXY3r25pc/2Ds0WhsqMHYx1NLFI 1338396334 Received: from localhost (unknown [31.45.20.151]) by mail.messagingengine.com (Postfix) with ESMTPA id 70ECE8E01A1; Wed, 30 May 2012 12:45:34 -0400 (EDT) Received: by localhost (Postfix, from userid 1000) id 730817E229B; Wed, 30 May 2012 18:45:30 +0200 (CEST) Date: Wed, 30 May 2012 18:45:30 +0200 From: Bron Gondwana To: Cyrus Daboo Message-ID: <20120530164530.GA4923@launde.brong.net> References: <798B43D6C44C87BB95E00D91@caldav.corp.apple.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <798B43D6C44C87BB95E00D91@caldav.corp.apple.com> Organization: brong.net User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Barry Leiba , imap5@ietf.org Subject: Re: [imap5] Proposal for "imapmove" working group 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, 30 May 2012 16:45:37 -0000 On Wed, May 30, 2012 at 12:22:09PM -0400, Cyrus Daboo wrote: > Are there existing client and server implementations of the > draft-gulbrandsen-imap-move right now? Does "implementation" also > cover actual interoperability testing, or does it only speak to the > actual ability to modify existing servers/clients to adopt the > extension? Cyrus git-master has XMOVE implemented. We use it in FastMail for our web interface to avoid quota issues when moving messages via the web interface rather than the old hack of working out the quota, then temporarily raising the limit, doing the copy+expunge and then reducing the limit again. Bron. From barryleiba@gmail.com Wed May 30 09:47:42 2012 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 C2EF711E80AE for ; Wed, 30 May 2012 09:47:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.969 X-Spam-Level: X-Spam-Status: No, score=-102.969 tagged_above=-999 required=5 tests=[AWL=0.008, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fOEy2nMtL0ja for ; Wed, 30 May 2012 09:47:42 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id D1C6221F865C for ; Wed, 30 May 2012 09:47:41 -0700 (PDT) Received: by yhq56 with SMTP id 56so18705yhq.31 for ; Wed, 30 May 2012 09:47:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type; bh=pDQzDYsUkBSuvkAZGKHG5+XBZ2V8nW4efqELmqisjrA=; b=tJLwScuFWzgSsgSiHChypY2w0gGDn6itnAfzzWvHJcJ34gsv5PbmLhGvNusHv70kXu GcAJCgKPbP4kj1NmlSaa3OiBRhMeWiWKQeOaEEFOAimDm0FIafDOr/vp6MBfh8rTPOek u5OcuOAGZX9bRGVC0y4HMfoCZ6//szXOY+D/VT3qgeY22nlxrRc+u2D32hSDi6993kWI veZc5XXqvOW57whcd74qpE94VM0VnFVpYYXgg+LqQ6p77lOb2Q9DFOIjCdXldGGK7gpV tV+dywVtX1yAFTeFMRiSQxdZE4umqCoaZkV9EgLj0i15/qHmZeS7s8LXe5qmX+NzrB7G WShg== MIME-Version: 1.0 Received: by 10.60.29.41 with SMTP id g9mr15633267oeh.18.1338396461309; Wed, 30 May 2012 09:47:41 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.60.21.35 with HTTP; Wed, 30 May 2012 09:47:41 -0700 (PDT) In-Reply-To: <798B43D6C44C87BB95E00D91@caldav.corp.apple.com> References: <798B43D6C44C87BB95E00D91@caldav.corp.apple.com> Date: Wed, 30 May 2012 12:47:41 -0400 X-Google-Sender-Auth: 0Cpqy6N023Cr8wF6EnfhMa0hZsU Message-ID: From: Barry Leiba To: imap5@ietf.org Content-Type: multipart/mixed; boundary=e89a8fb2033aa5207904c143b5c1 Subject: Re: [imap5] Proposal for "imapmove" working group 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, 30 May 2012 16:47:42 -0000 --e89a8fb2033aa5207904c143b5c1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Wed, May 30, 2012 at 12:22 PM, Cyrus Daboo wrote: > Which mailing list? imapext or imap5? Typo (or braino). There is no "imapext" list. >> flagged for deletion, the third step has the side effect of expunging > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0^^^ > > Really it is "can have the side effect" since clients might have the opti= on > of using UID EXPUNGE But UID EXPUNGE is part of the UIDPLUS extension, not in base IMAP (and I'm not sure how widely deployed UIDPLUS is. And, as you say, one would have to be mentally unstable to try to work around this the other way. Still, "can have" is fine, and I've changed the text. >> The IMAP MOVE extension (imapmove) working group has the single task >> of developing an atomic IMAP MOVE command that will move a set of > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0^^^^^^ =A0 =A0 =A0 =A0 =A0 ^^^^^^^ > Use "extension" instead of "command" as the actual command is "UID MOVE" = as > per Arnt's spec. As per Timo, I am not sure we should state it will be > "atomic" as that may restrict what we do in the spec. It's meant to be "atomic" from the client's view, whether or not it's atomic in the server. But I prefer your later suggestion of "single command", so I've changed it accordingly. > Are there existing client and server implementations of the > draft-gulbrandsen-imap-move right now? So Arnt tells me. > Does "implementation" also cover > actual interoperability testing, or does it only speak to the actual abil= ity > to modify existing servers/clients to adopt the extension? If there's interop testing, it would be very fine to document that here. But that's not what this is about; this is to show that there's a real need for this, and active work on implementations (as opposed to our developing another IMAP extension that gets essentially no use). Attached is the latest charter version, with these changes. Barry --e89a8fb2033aa5207904c143b5c1 Content-Type: text/plain; charset=US-ASCII; name="charter-ietf-imapmove-00-01-00.txt" Content-Disposition: attachment; filename="charter-ietf-imapmove-00-01-00.txt" Content-Transfer-Encoding: base64 X-Attachment-Id: f_h2umott20 SU1BUCBNT1ZFIGV4dGVuc2lvbiAoaW1hcG1vdmUpCgpDaGFpcihzKTogVEJEIAoKQXBwbGljYXRp b25zIEFyZWEgRGlyZWN0b3Iocyk6CiAgUGV0ZSBSZXNuaWNrIDxwcmVzbmlja0BxdWFsY29tbS5j b20+IAogIEJhcnJ5IExlaWJhIDxiYXJyeWxlaWJhQGNvbXB1dGVyLm9yZz4gCgpNYWlsaW5nIExp c3RzOgogIEdlbmVyYWwgRGlzY3Vzc2lvbjogaW1hcDVAaWV0Zi5vcmcKICBUbyBTdWJzY3JpYmU6 ICAgICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaW1hcDUKICBBcmNo aXZlOiAgICAgICAgICAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9pbWFw NS8KIApEZXNjcmlwdGlvbiBvZiBXb3JraW5nIEdyb3VwOgoKVGhlIEludGVybmV0IE1lc3NhZ2Ug QWNjZXNzIFByb3RvY29sIChJTUFQKSwgZGVmaW5lZCBpbiBSRkMgMzUwMSwKc3BlY2lmaWVzIGEg cHJvdG9jb2wgZm9yIHRyYW5zZmVycmluZyBlbWFpbCBtZXNzYWdlcyBiZXR3ZWVuIGEgc2VydmVy CnRoYXQgaW1wbGVtZW50cyBhIG1lc3NhZ2Ugc3RvcmUsIGFuZCBhIGNsaWVudC4gIEl0IGFsc28g aW5jbHVkZXMKY29tbWFuZHMgZm9yIG1hbmlwdWxhdGluZyB0aGUgbWVzc2FnZSBzdG9yZSAtLSBj cmVhdGluZywgZGVsZXRpbmcsIGFuZApyZW5hbWluZyBtYWlsYm94ZXMsIGFkZGluZyBhIG1lc3Nh Z2UgdG8gYSBtYWlsYm94LCBhbmQgY29weWluZwptZXNzYWdlcyBmcm9tIG9uZSBtYWlsYm94IHRv IGFub3RoZXIuCgpJdCdzIG9mdGVuIHRoZSBjYXNlIHRoYXQgYW4gSU1BUCBjbGllbnQgbmVlZHMg dG8gbW92ZSAobm90IGNvcHkpCm1lc3NhZ2VzIGZyb20gb25lIG1haWxib3ggdG8gYW5vdGhlci4g IFRoZSBtZWNoYW5pc20gdGhhdCBJTUFQCnByb3ZpZGVzIHRvIGRvIHRoYXQgaXMgYSBtdWx0aS1z dGVwIHByb2Nlc3M6CjEuIENvcHkgdGhlIG1lc3NhZ2VzIGZyb20gdGhlIHNvdXJjZSBtYWlsYm94 IHRvIHRoZSB0YXJnZXQgbWFpbGJveC4KMi4gRmxhZyB0aGUgb3JpZ2luYWwgbWVzc2FnZXMgaW4g dGhlIHNvdXJjZSBtYWlsYm94IGFzIGRlbGV0ZWQuCjMuIEV4cHVuZ2UgdGhlIGRlbGV0ZWQgbWVz c2FnZXMgZnJvbSB0aGUgc291cmNlIG1haWxib3guCgpJbXBsZW1lbnRvcnMgaGF2ZSBsb25nIHBv aW50ZWQgb3V0IHNvbWUgc2hvcnRjb21pbmdzIHdpdGggdGhpcwphcHByb2FjaC4gIEJlY2F1c2Ug dGhlIG1vdmluZyBvZiBhIG1lc3NhZ2UgaXMgbm90IGFuIGF0b21pYyBwcm9jZXNzLAppbnRlcnJ1 cHRpb25zIGNhbiBsZWF2ZSBtZXNzYWdlcyBpbiBpbnRlcm1lZGlhdGUgc3RhdGVzLiAgQmVjYXVz ZQptdWx0aXBsZSBjbGllbnRzIGNhbiBiZSBhY2Nlc3NpbmcgdGhlIG1haWxib3hlcyBhdCB0aGUg c2FtZSB0aW1lLApjbGllbnRzIGNhbiBzZWUgbWVzc2FnZXMgaW4gaW50ZXJtZWRpYXRlIHN0YXRl cyBldmVuIHdpdGhvdXQKaW50ZXJydXB0aW9ucy4gIElmIHRoZSBzb3VyY2UgbWFpbGJveCBjb250 YWlucyBvdGhlciBtZXNzYWdlcyB0aGF0IGFyZQpmbGFnZ2VkIGZvciBkZWxldGlvbiwgdGhlIHRo aXJkIHN0ZXAgY2FuIGhhdmUgdGhlIHNpZGUgZWZmZWN0IG9mCmV4cHVuZ2luZyBtb3JlIHRoYW4g anVzdCB0aGUgc2V0IG9mIG1vdmVkIG1lc3NhZ2VzLiAgQW5kIHNlcnZlcnMgd2l0aApjZXJ0YWlu IHR5cGVzIG9mIGJhY2stZW5kIG1lc3NhZ2Ugc3RvcmVzIG1pZ2h0IGhhdmUgZWZmaWNpZW50IHdh eXMgb2YKbW92aW5nIG1lc3NhZ2VzLCB3aGljaCBkb24ndCBpbnZvbHZlIGFjdHVhbCBjb3B5aW5n IG9mIGRhdGEuICBTdWNoCmVmZmljaWVuY2llcyBhcmUgb2Z0ZW4gbm90IGF2YWlsYWJsZSB0byB0 aGUgY29weS9mbGFnL2V4cHVuZ2UgcHJvY2Vzcy4KClRoZSBJTUFQIE1PVkUgZXh0ZW5zaW9uIChp bWFwbW92ZSkgd29ya2luZyBncm91cCBoYXMgdGhlIHNpbmdsZSB0YXNrCm9mIGRldmVsb3Bpbmcg YW4gSU1BUCBNT1ZFIGV4dGVuc2lvbiB0aGF0IGRlZmluZXMgYSBzaW5nbGUgY29tbWFuZCB0bwpt b3ZlIGEgc2V0IG9mIG1lc3NhZ2VzIGZyb20gYSBzb3VyY2UgbWFpbGJveCB0byBhIHRhcmdldCBt YWlsYm94IGluIGEKc2luZ2xlIG9wZXJhdGlvbi4gIFRoZSBncm91cCB3aWxsIHVzZSBkcmFmdC1n dWxicmFuZHNlbi1pbWFwLW1vdmUgYXMgYQpzdGFydGluZyBwb2ludCwgYW5kIHdpbGwgcHJvZHVj ZSBhIFN0YW5kYXJkcyBUcmFjayBkb2N1bWVudC4KCkFzIHBhcnQgb2YgdGhlIHByb3RvY29sIGRl dmVsb3BtZW50LCBpbXBsZW1lbnRhdGlvbiBleHBlcmllbmNlIG9uIGJvdGgKdGhlIGNsaWVudCBh bmQgc2VydmVyIHNpZGUgaXMgaGlnaGx5IGRlc2lyZWFibGUsIHNvIHRoYXQgdGhlIGFjdHVhbApv cGVyYXRpb25hbCB2YWx1ZSBvZiB0aGlzIGV4dGVuc2lvbiBjYW4gYmUgYXNzZXNzZWQuIFRoZSB3 b3JraW5nIGdyb3VwCndpbGwgZG9jdW1lbnQgdGhlIHJlc3VsdHMgb2YgdGhpcyBleHBlcmllbmNl IG9uIHRoZSB3b3JraW5nIGdyb3VwCndpa2kuCgpObyBvdGhlciBJTUFQIGV4dGVuc2lvbiB3b3Jr IGlzIGluIHNjb3BlIGZvciB0aGlzIHdvcmtpbmcgZ3JvdXAuCgpNaWxlc3RvbmVzCgowNy8yMDEy ICAgIEluaXRpYWwgYWRvcHRpb24gb2YgSU1BUCBNT1ZFIHByb3RvY29sIGRvY3VtZW50CjA3LzIw MTIgICAgRXN0YWJsaXNobWVudCBvZiBpbXBsZW1lbnRhdGlvbiB0cmFja2luZyBvbiB0aGUgd29y a2luZwogICAgICAgICAgIGdyb3VwIHdpa2kKMDgvMjAxMiAgICBJbml0aWFsIGFzc2Vzc21lbnQg b2YgaW1wbGVtZW50YXRpb24gcmVzdWx0cwowOS8yMDEyICAgIEZpbmFsIHJlcG9ydCBvbiBpbXBs ZW1lbnRhdGlvbiByZXN1bHRzCjEwLzIwMTIgICAgSU1BUCBNT1ZFIHByb3RvY29sIGRvY3VtZW50 IHRvIElFU0cgYXMgUHJvcG9zZWQgU3RhbmRhcmQK --e89a8fb2033aa5207904c143b5c1-- From tss@iki.fi Wed May 30 09:59:21 2012 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 0487A11E80C9 for ; Wed, 30 May 2012 09:59:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.08 X-Spam-Level: X-Spam-Status: No, score=-110.08 tagged_above=-999 required=5 tests=[AWL=0.519, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vWZJpyB5QJ0b for ; Wed, 30 May 2012 09:59:20 -0700 (PDT) Received: from dovecot.org (dovecot.org [193.210.130.67]) by ietfa.amsl.com (Postfix) with ESMTP id 5005811E8099 for ; Wed, 30 May 2012 09:59:20 -0700 (PDT) Received: from [192.168.10.101] (a88-112-255-76.elisa-laajakaista.fi [88.112.255.76]) by dovecot.org (Postfix) with ESMTP id 706D61AE876B for ; Wed, 30 May 2012 19:59:19 +0300 (EEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1084) From: Timo Sirainen In-Reply-To: Date: Wed, 30 May 2012 19:59:19 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <44D82C6F-4134-47A0-AD23-64FC6585A362@iki.fi> References: <798B43D6C44C87BB95E00D91@caldav.corp.apple.com> To: "Discussion on drastically slimming-down IMAP." X-Mailer: Apple Mail (2.1084) Subject: Re: [imap5] Proposal for "imapmove" working group 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, 30 May 2012 16:59:21 -0000 On 30.5.2012, at 19.47, Barry Leiba wrote: >> Are there existing client and server implementations of the >> draft-gulbrandsen-imap-move right now? >=20 > So Arnt tells me. If I can implement it this way without violating the spec: 1. Verify that ACLs allow expunge, fail if not 2. Do atomic UID COPY without enforcing quota limits 3. Expunge the messages [4. If expunge for some strange reason fails now, there are probably = duplicates now. I'm not sure if I want to bother fixing that situation. = It should "never" happen anyway.] then I could add it to Dovecot pretty much immediately. From alexey.melnikov@isode.com Wed May 30 10:04:23 2012 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 0AB9221F859F for ; Wed, 30 May 2012 10:04:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.522 X-Spam-Level: X-Spam-Status: No, score=-102.522 tagged_above=-999 required=5 tests=[AWL=0.077, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pIb9ZJoGVHew for ; Wed, 30 May 2012 10:04:22 -0700 (PDT) Received: from rufus.isode.com (cl-125.lon-03.gb.sixxs.net [IPv6:2a00:14f0:e000:7c::2]) by ietfa.amsl.com (Postfix) with ESMTP id EA5D221F8569 for ; Wed, 30 May 2012 10:04:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1338397461; d=isode.com; s=selector; i=@isode.com; bh=l94uXpFVkH6+zP24MDwoTbS7W2rlpVK2/5tsxNvL6L8=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=OrjqC2BYiJPTo1oG5pCq6mC46h6AYBfkF+iiKVHmgNFl18op4Pi7g7JhhyLLgZ9h2gxTnN 4sJqOiAXVXwz4l9eYom9B9bpO+x8361fOBlACnesHq6AKJF/tSCXLq1LRaN0Otr0neoNbj HUTsj35yQi1DW58ze+HCoCZM91sOO+4=; Received: from [172.16.1.29] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPSA id ; Wed, 30 May 2012 18:04:21 +0100 X-SMTP-Protocol-Errors: PIPELINING Message-ID: <4FC65317.9040702@isode.com> Date: Wed, 30 May 2012 18:04:23 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 To: Barry Leiba References: <798B43D6C44C87BB95E00D91@caldav.corp.apple.com> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: imap5@ietf.org Subject: Re: [imap5] Proposal for "imapmove" working group 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, 30 May 2012 17:04:23 -0000 On 30/05/2012 17:47, Barry Leiba wrote: > On Wed, May 30, 2012 at 12:22 PM, Cyrus Daboo wrote: [...] >>> flagged for deletion, the third step has the side effect of expunging >> ^^^ >> >> Really it is "can have the side effect" since clients might have the option >> of using UID EXPUNGE > But UID EXPUNGE is part of the UIDPLUS extension, not in base IMAP > (and I'm not sure how widely deployed UIDPLUS is. A side note: it is very widely deployed. As far as I am concerned, if a server doesn't implement UIDPLUS, it is pretty much unusable and unlikely to work with a general purpose IMAP client. > And, as you say, > one would have to be mentally unstable to try to work around this the > other way. Still, "can have" is fine, and I've changed the text. From cyrus@daboo.name Wed May 30 10:11:30 2012 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 5133D21F8633 for ; Wed, 30 May 2012 10:11:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T-zIR7B-HOA5 for ; Wed, 30 May 2012 10:11:29 -0700 (PDT) Received: from daboo.name (daboo.name [173.13.55.49]) by ietfa.amsl.com (Postfix) with ESMTP id DBAB821F8636 for ; Wed, 30 May 2012 10:11:28 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by daboo.name (Postfix) with ESMTP id 636462833B88; Wed, 30 May 2012 13:11:28 -0400 (EDT) X-Virus-Scanned: amavisd-new at daboo.name Received: from daboo.name ([127.0.0.1]) by localhost (daboo.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CBp8jdsT+hLk; Wed, 30 May 2012 13:11:22 -0400 (EDT) Received: from caldav.corp.apple.com (unknown [17.45.162.46]) by daboo.name (Postfix) with ESMTPSA id E3F992833B78; Wed, 30 May 2012 13:11:21 -0400 (EDT) Date: Wed, 30 May 2012 13:11:19 -0400 From: Cyrus Daboo To: Barry Leiba , imap5@ietf.org Message-ID: <45BC9626193BD507CCDBB02D@caldav.corp.apple.com> In-Reply-To: References: <798B43D6C44C87BB95E00D91@caldav.corp.apple.com> X-Mailer: Mulberry/4.1.0a3 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline; size=1384 Subject: Re: [imap5] Proposal for "imapmove" working group 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, 30 May 2012 17:11:30 -0000 Hi Barry, --On May 30, 2012 12:47:41 PM -0400 Barry Leiba wrote: >> Which mailing list? imapext or imap5? > > Typo (or braino). There is no "imapext" list. Well there is, just not quite what you wrote: List-Archive: List-ID: That list is still active to some extent and might be more appropriate for an extension to IMAP rather than "IMAP 5", but I am not bothered either way. >> Really it is "can have the side effect" since clients might have the >> option of using UID EXPUNGE > > But UID EXPUNGE is part of the UIDPLUS extension, not in base IMAP > (and I'm not sure how widely deployed UIDPLUS is. And, as you say, > one would have to be mentally unstable to try to work around this the > other way. Still, "can have" is fine, and I've changed the text. Hehe - well I guess I must have been mentally unstable at some point in time because I did actually implement the "undelete, sequence expunge, redelete" behavior in Mulberry to handle the case of a non UIDPLUS server - however that is only used when playing back disconnected operations where an expunge was explicitly triggered by the user whilst offline. In Mulberry the "move" operation simply does copy + mark deleted - it does not expunge - the user is on the hook to explicitly do that. -- Cyrus Daboo From cyrus@daboo.name Wed May 30 10:20:37 2012 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 6D94511E8099 for ; Wed, 30 May 2012 10:20:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aOgszLlp+Lkb for ; Wed, 30 May 2012 10:20:35 -0700 (PDT) Received: from daboo.name (daboo.name [173.13.55.49]) by ietfa.amsl.com (Postfix) with ESMTP id DFEEF11E8097 for ; Wed, 30 May 2012 10:20:34 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by daboo.name (Postfix) with ESMTP id 6824C2833D26; Wed, 30 May 2012 13:20:34 -0400 (EDT) X-Virus-Scanned: amavisd-new at daboo.name Received: from daboo.name ([127.0.0.1]) by localhost (daboo.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LbKPSnf5FyL3; Wed, 30 May 2012 13:20:30 -0400 (EDT) Received: from caldav.corp.apple.com (unknown [17.45.162.46]) by daboo.name (Postfix) with ESMTPSA id 966A92833D19; Wed, 30 May 2012 13:20:29 -0400 (EDT) Date: Wed, 30 May 2012 13:20:26 -0400 From: Cyrus Daboo To: Timo Sirainen , "Discussion on drastically slimming-down IMAP." Message-ID: X-Mailer: Mulberry/4.1.0a3 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline; size=1055 Subject: [imap5] Should unsolicited EXPUNGE responses be returned during UID MOVE? 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, 30 May 2012 17:20:37 -0000 Hi Timo, (Changing thread since we are now into a technical issue rather than charter) --On May 30, 2012 7:59:19 PM +0300 Timo Sirainen wrote: >> So Arnt tells me. > > If I can implement it this way without violating the spec: > > 1. Verify that ACLs allow expunge, fail if not > 2. Do atomic UID COPY without enforcing quota limits > 3. Expunge the messages > [4. If expunge for some strange reason fails now, there are probably > duplicates now. I'm not sure if I want to bother fixing that situation. > It should "never" happen anyway.] > > then I could add it to Dovecot pretty much immediately. So if the expunge does fail, how are you going to report that to the client? Arnt's current spec does not show any * N EXPUNGE responses coming back, so I am assuming that the client is supposed to implicitly assume the expunges took place, which would cause a problem if they did not take place. But that seems wrong to me - shouldn't UID MOVE cause * N EXPUNGE to be sent for each message that was actually moved? -- Cyrus Daboo From barryleiba@gmail.com Wed May 30 10:24:09 2012 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 497AF11E80C1 for ; Wed, 30 May 2012 10:24:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.969 X-Spam-Level: X-Spam-Status: No, score=-102.969 tagged_above=-999 required=5 tests=[AWL=0.008, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GT1gT8nAkjBC for ; Wed, 30 May 2012 10:24:08 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7BAEE11E80BB for ; Wed, 30 May 2012 10:24:08 -0700 (PDT) Received: by obbeh20 with SMTP id eh20so57903obb.31 for ; Wed, 30 May 2012 10:24:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type :content-transfer-encoding; bh=Ab345uzIRUgJVmlxgM6v8WQmGJYww3yUR6u7XQSkskQ=; b=rHKiYs3aJmLLUDIhMObTP8n1t/tFeizw6Jb4WwAQJSYplm9etu91Yw8V2VMc273HnW mCOOxkybJ0vK8hsMRVBuB8qt3nFVhzV62JLMXV5DBVNFWeCkJODO65vaZCr9p6DYxUBL Ca+Ny1EIMgos0THMJKXK7Xi7eFzLCHXRldwdbBTGHBhS5cLoLmf1VvMuCxE+Zt6/cH7k JPr5kuGyBri/dEv4MpubqrkLHTQeQvd+6zMzNBZjjXyYrSchLZckHUGzefk07BbFN2ti md1As/q6mWwI6znpyrpZjF+egn3fRIs8fcsAR2BVxuSHtn+H6kmFGZPXy7dQQ2QuUoyT HD3A== MIME-Version: 1.0 Received: by 10.60.28.37 with SMTP id y5mr676186oeg.35.1338398647922; Wed, 30 May 2012 10:24:07 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.60.21.35 with HTTP; Wed, 30 May 2012 10:24:07 -0700 (PDT) In-Reply-To: <45BC9626193BD507CCDBB02D@caldav.corp.apple.com> References: <798B43D6C44C87BB95E00D91@caldav.corp.apple.com> <45BC9626193BD507CCDBB02D@caldav.corp.apple.com> Date: Wed, 30 May 2012 13:24:07 -0400 X-Google-Sender-Auth: tu8Uxaoxcv9tE1zHnA4K4wsOuVg Message-ID: From: Barry Leiba To: imap5@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [imap5] Proposal for "imapmove" working group 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, 30 May 2012 17:24:09 -0000 >> Typo (or braino). =A0There is no "imapext" list. > > Well there is, just not quite what you wrote: > > List-Archive: > List-ID: Right; that's not an "imapext" list, it's an "ietf-imapext" list. And it doesn't live at ietf.org. So, no, not what I meant at all. The IESG very strongly wants to use mailing lists at ietf.org, unless there's a very good reason not to. We could create a new list, or use the not-very-active imap5 list for a few months. The latter seemed better to me, since many of the people who will want to follow this are already there. I'm happy to instead create a new list, if consensus goes that way. Barry From tss@iki.fi Wed May 30 10:27:25 2012 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 ECC3311E80D2 for ; Wed, 30 May 2012 10:27:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.253 X-Spam-Level: X-Spam-Status: No, score=-110.253 tagged_above=-999 required=5 tests=[AWL=0.346, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SGKMdhCThijG for ; Wed, 30 May 2012 10:27:25 -0700 (PDT) Received: from dovecot.org (dovecot.org [193.210.130.67]) by ietfa.amsl.com (Postfix) with ESMTP id 359FC11E80BB for ; Wed, 30 May 2012 10:27:25 -0700 (PDT) Received: from [192.168.10.101] (a88-112-255-76.elisa-laajakaista.fi [88.112.255.76]) by dovecot.org (Postfix) with ESMTP id 976EF1AE8823; Wed, 30 May 2012 20:27:23 +0300 (EEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Timo Sirainen In-Reply-To: Date: Wed, 30 May 2012 20:27:22 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <76722931-7258-4A3F-9F60-14DA74FC8B1A@iki.fi> References: To: Cyrus Daboo X-Mailer: Apple Mail (2.1084) Cc: "Discussion on drastically slimming-down IMAP." Subject: Re: [imap5] Should unsolicited EXPUNGE responses be returned during UID MOVE? 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, 30 May 2012 17:27:26 -0000 On 30.5.2012, at 20.20, Cyrus Daboo wrote: >>> So Arnt tells me. >>=20 >> If I can implement it this way without violating the spec: >>=20 >> 1. Verify that ACLs allow expunge, fail if not >> 2. Do atomic UID COPY without enforcing quota limits >> 3. Expunge the messages >> [4. If expunge for some strange reason fails now, there are probably >> duplicates now. I'm not sure if I want to bother fixing that = situation. >> It should "never" happen anyway.] >>=20 >> then I could add it to Dovecot pretty much immediately. >=20 > So if the expunge does fail, how are you going to report that to the = client? Arnt's current spec does not show any * N EXPUNGE responses = coming back, so I am assuming that the client is supposed to implicitly = assume the expunges took place, which would cause a problem if they did = not take place. But that seems wrong to me - shouldn't UID MOVE cause * = N EXPUNGE to be sent for each message that was actually moved? I assumed that this was a bug in the example and was going to report it = as some point. I think the EXPUNGE/VANISHED replies should be sent in = any case, even if MOVE was required to be fully atomic. Otherwise if the = UID MOVE command sends an untagged FETCH/EXPUNGE reply it wouldn't be = obvious if the sequence number referred to the state before or after the = MOVE expunges. From alexey.melnikov@isode.com Wed May 30 10:56:18 2012 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 4272011E80AE for ; Wed, 30 May 2012 10:56:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.476 X-Spam-Level: X-Spam-Status: No, score=-102.476 tagged_above=-999 required=5 tests=[AWL=0.123, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MQkgYMnEvzA6 for ; Wed, 30 May 2012 10:56:17 -0700 (PDT) Received: from rufus.isode.com (cl-125.lon-03.gb.sixxs.net [IPv6:2a00:14f0:e000:7c::2]) by ietfa.amsl.com (Postfix) with ESMTP id 4CEE811E808D for ; Wed, 30 May 2012 10:56:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1338400576; d=isode.com; s=selector; i=@isode.com; bh=pWetcDp9n7mDp8w4fFhvGh2GZ01RjIReLUWEQijhi/w=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=szcncBG52Mb9uw4MIT9r/3uDob7JKF4bRrYKTxvNLAp+uptd7ZomP9JQtKHcyA2AdJQ6Bs CMC39Ee0A4XCuN2xiyUz8dlHow9hCSqyMSasC2x7tBMRdJmw5AGcV+wdsSe5bNMWSKkI+o 151O0NV/7jNpK2E97DK/40ROS/ob734=; Received: from [172.16.1.29] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPSA id ; Wed, 30 May 2012 18:56:16 +0100 X-SMTP-Protocol-Errors: PIPELINING Message-ID: <4FC65F3E.7070206@isode.com> Date: Wed, 30 May 2012 18:56:14 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 To: Cyrus Daboo References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Timo Sirainen , "Discussion on drastically slimming-down IMAP." Subject: Re: [imap5] Should unsolicited EXPUNGE responses be returned during UID MOVE? 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, 30 May 2012 17:56:18 -0000 On 30/05/2012 18:20, Cyrus Daboo wrote: > Hi Timo, > (Changing thread since we are now into a technical issue rather than > charter) > > --On May 30, 2012 7:59:19 PM +0300 Timo Sirainen wrote: > >>> So Arnt tells me. >> >> If I can implement it this way without violating the spec: >> >> 1. Verify that ACLs allow expunge, fail if not >> 2. Do atomic UID COPY without enforcing quota limits >> 3. Expunge the messages >> [4. If expunge for some strange reason fails now, there are probably >> duplicates now. I'm not sure if I want to bother fixing that situation. >> It should "never" happen anyway.] >> >> then I could add it to Dovecot pretty much immediately. > > So if the expunge does fail, how are you going to report that to the > client? Arnt's current spec does not show any * N EXPUNGE responses > coming back, so I am assuming that the client is supposed to > implicitly assume the expunges took place, which would cause a problem > if they did not take place. But that seems wrong to me - shouldn't UID > MOVE cause * N EXPUNGE to be sent for each message that was actually > moved? Yes, I think lack of EXPUNGE responses is an error for reasons stated by Timo. From arnt@gulbrandsen.priv.no Wed May 30 13:43:40 2012 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 695D421F8738 for ; Wed, 30 May 2012 13:43:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.856 X-Spam-Level: X-Spam-Status: No, score=-1.856 tagged_above=-999 required=5 tests=[AWL=0.744, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vIEJEf3TaAeJ for ; Wed, 30 May 2012 13:43:39 -0700 (PDT) Received: from strange.aox.org (strange.aox.org [IPv6:2001:4d88:100c::1]) by ietfa.amsl.com (Postfix) with ESMTP id 528F721F8739 for ; Wed, 30 May 2012 13:43:39 -0700 (PDT) Received: from fri.gulbrandsen.priv.no (unknown [127.0.0.1]) by strange.aox.org (Postfix) with ESMTP id 4CB6FF8CE6D; Wed, 30 May 2012 20:43:38 +0000 (UTC) Received: from arnt@gulbrandsen.priv.no by fri.gulbrandsen.priv.no (Archiveopteryx 3.1.4) with esmtpsa id 1338410617-10044-10043/11/2; Wed, 30 May 2012 20:43:37 +0000 Message-Id: <4FC68677.5060101@gulbrandsen.priv.no> Date: Wed, 30 May 2012 22:43:35 +0200 From: Arnt Gulbrandsen User-Agent: Mozilla/5.0 (X11; Linux i686; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 Mime-Version: 1.0 To: imap5@ietf.org References: <798B43D6C44C87BB95E00D91@caldav.corp.apple.com> In-Reply-To: <798B43D6C44C87BB95E00D91@caldav.corp.apple.com> Content-Type: text/plain; charset=iso-8859-1; format=flowed Subject: Re: [imap5] Proposal for "imapmove" working group 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, 30 May 2012 20:43:40 -0000 On 05/30/2012 06:22 PM, Cyrus Daboo wrote: > Are there existing client and server implementations of the > draft-gulbrandsen-imap-move right now? Does "implementation" also cover > actual interoperability testing, or does it only speak to the actual > ability to modify existing servers/clients to adopt the extension? There are several servers which do what the document describes. I know of several "clients" too, but perhaps not as you'd see it. Technically a perl script that classifies and moves mail is a client, right? https://jira.zarafa.com/browse/ZCP-6695 may be interesting to you. No, Zarafa has nothing to do with AOL. Arnt From adrien@qbik.com Wed May 30 14:06:59 2012 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 EC05421F8663 for ; Wed, 30 May 2012 14:06:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4SIJQXXKN9-4 for ; Wed, 30 May 2012 14:06:59 -0700 (PDT) Received: from smtp.qbik.com (smtp.qbik.com [210.55.214.35]) by ietfa.amsl.com (Postfix) with ESMTP id 25F9021F8649 for ; Wed, 30 May 2012 14:06:58 -0700 (PDT) Received: From [192.168.1.10] (unverified [219.89.218.74]) by SMTP Server [210.55.214.35] (WinGate SMTP Receiver v7.2.1 (Build 3414)) with SMTP id <0019053816@smtp.qbik.com>; Thu, 31 May 2012 09:06:56 +1200 From: "Adrien W. de Croy" To: "Cyrus Daboo" , "Barry Leiba" , "imap5@ietf.org" Date: Wed, 30 May 2012 21:07:28 +0000 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; format=flowed; charset=utf-8 In-Reply-To: <798B43D6C44C87BB95E00D91@caldav.corp.apple.com> Message-Id: Mime-Version: 1.0 User-Agent: eM_Client/4.0.14522.0 Subject: Re: [imap5] Proposal for "imapmove" working group X-BeenThere: imap5@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: "Adrien W. de Croy" List-Id: "Discussion on drastically slimming-down IMAP." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 May 2012 21:07:00 -0000 =EF=BB=BF ------ Original Message ------ From: "Cyrus Daboo" To: "Barry Leiba" ;"imap5@ietf.org" > >Are there existing client and server implementations of the >draft-gulbrandsen-imap-move right now? Does "implementation" also >cover actual interoperability testing, or does it only speak to the >actual ability to modify existing servers/clients to adopt the >extension? WinGate has had it for a while now. We noticed speed improvements using it with Thunderbird for mail filtering. Our server has a naive (aka deep) COPY using Maildir style. We still support windows 2000 which doesn't support CreateHardLink. Scheduled to drop support for 2k soon though. Will definitely be looking to improve COPY with this. The current mail client I use doesn't do MOVE though. It is slightly slower on filtering for that reason, esp on higher latency connections to the server (more R-Ts). We don't do nested locks either, although it's feasible to do lock checks prior to locking to error back to the client rather than deadlock (classic 2 thread deadlock issue). We also support MOVE (without UID). It resolves source msgids to UIDs inside a lock of the source before effectively doing a MOVE. This is probably error-prone in some pathological border cases, but I think the = effect at worst would be a resynch in the interfering client. Adrien > > > >-- Cyrus Daboo > >_______________________________________________ >imap5 mailing list >imap5@ietf.org >https://www.ietf.org/mailman/listinfo/imap5 From adrien@qbik.com Wed May 30 14:10:41 2012 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 79FB021F86A4 for ; Wed, 30 May 2012 14:10:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1XF5F3RMjdOn for ; Wed, 30 May 2012 14:10:40 -0700 (PDT) Received: from smtp.qbik.com (smtp.qbik.com [210.55.214.35]) by ietfa.amsl.com (Postfix) with ESMTP id 03AD321F8679 for ; Wed, 30 May 2012 14:10:39 -0700 (PDT) Received: From [192.168.1.10] (unverified [219.89.218.74]) by SMTP Server [210.55.214.35] (WinGate SMTP Receiver v7.2.1 (Build 3414)) with SMTP id <0019053826@smtp.qbik.com>; Thu, 31 May 2012 09:10:38 +1200 From: "Adrien W. de Croy" To: "Timo Sirainen" , "Cyrus Daboo" Date: Wed, 30 May 2012 21:11:12 +0000 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; format=flowed; charset=utf-8 In-Reply-To: <76722931-7258-4A3F-9F60-14DA74FC8B1A@iki.fi> Message-Id: Mime-Version: 1.0 User-Agent: eM_Client/4.0.14522.0 Cc: "Discussion on drastically slimming-down IMAP." Subject: Re: [imap5] Should unsolicited EXPUNGE responses be returned during UID MOVE? X-BeenThere: imap5@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: "Adrien W. de Croy" List-Id: "Discussion on drastically slimming-down IMAP." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 May 2012 21:10:41 -0000 what about using the sequences in the final tagged response as an indication of what was actually successfully moved.. the ones that map = source messages to new UIDs. We suppress EXPUNGE responses during MOVE already. When you're moving a large set of messages, this improves things quite a bit in terms of bw and speed. ---- Adrien de Croy - WinGate Proxy Server - http://www.wingate.com WinGate 7 is released! - http://www.wingate.com/getlatest/ ------ Original Message ------ From: "Timo Sirainen" To: "Cyrus Daboo" Cc: "Discussion on drastically slimming-down IMAP." Sent: 31/05/2012 5:27:22 a.m. Subject: Re: [imap5] Should unsolicited EXPUNGE responses be returned during UID MOVE? >On 30.5.2012, at 20.20, Cyrus Daboo wrote: > > >>>> >>>>So Arnt tells me. >>>> >>> >>> >>>If I can implement it this way without violating the spec: >>> >>>1. Verify that ACLs allow expunge, fail if not >>>2. Do atomic UID COPY without enforcing quota limits >>>3. Expunge the messages >>>[4. If expunge for some strange reason fails now, there are probably >>>duplicates now. I'm not sure if I want to bother fixing that situation.= >>>It should "never" happen anyway.] >>> >>>then I could add it to Dovecot pretty much immediately. >>> >> >> >>So if the expunge does fail, how are you going to report that to the clie= nt? Arnt's current spec does not show any * N EXPUNGE responses coming back= , so I am assuming that the client is supposed to implicitly assume the exp= unges took place, which would cause a problem if they did not take place. B= ut that seems wrong to me - shouldn't UID MOVE cause * N EXPUNGE to be sent= for each message that was actually moved? >> > > >I assumed that this was a bug in the example and was going to report it as= some point. I think the EXPUNGE/VANISHED replies should be sent in any cas= e, even if MOVE was required to be fully atomic. Otherwise if the UID MOVE = command sends an untagged FETCH/EXPUNGE reply it wouldn't be obvious if the= sequence number referred to the state before or after the MOVE expunges.= > >_______________________________________________ >imap5 mailing list >imap5@ietf.org >https://www.ietf.org/mailman/listinfo/imap5 > > From jkt@flaska.net Wed May 30 14:32:40 2012 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 3FBFE11E80DF for ; Wed, 30 May 2012 14:32:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.35 X-Spam-Level: X-Spam-Status: No, score=-0.35 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, J_CHICKENPOX_47=0.6, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FZOh+dof3kRN for ; Wed, 30 May 2012 14:32:39 -0700 (PDT) Received: from serv132.fzu.cz (serv132.fzu.cz [147.231.26.132]) by ietfa.amsl.com (Postfix) with ESMTP id 2805711E80C5 for ; Wed, 30 May 2012 14:32:38 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAIuRxk+T5xpZ/2dsb2JhbABEhUquSYEHghcBAQUjVRELGAkWCwICCQMCAQIBRRMIAQGIB6ZhkkqLGgUCghSCBIESA441gR2FRoEPjmSCYoFUAQgX X-IronPort-AV: E=Sophos;i="4.75,686,1330902000"; d="asc'?scan'208";a="6051803" Received: from freja.fzu.cz ([147.231.26.89]) by serv147.fzu.cz with ESMTP; 30 May 2012 23:32:35 +0200 Received: from svist.flaska.net (pc069c.fzu.cz [147.231.27.69]) by freja.fzu.cz (Postfix) with ESMTPSA id A55EA3DA82 for ; Wed, 30 May 2012 23:32:35 +0200 (CEST) Message-ID: <4FC691E6.1080708@flaska.net> Date: Wed, 30 May 2012 23:32:22 +0200 From: =?UTF-8?B?SmFuIEt1bmRyw6F0?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.3) Gecko/20120306 Thunderbird/10.0.3 MIME-Version: 1.0 To: imap5@ietf.org References: <798B43D6C44C87BB95E00D91@caldav.corp.apple.com> <20120530164530.GA4923@launde.brong.net> In-Reply-To: <20120530164530.GA4923@launde.brong.net> X-Enigmail-Version: 1.4 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig545574EB81591BBA9505B439" Subject: Re: [imap5] Proposal for "imapmove" working group 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, 30 May 2012 21:32:40 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig545574EB81591BBA9505B439 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 05/30/12 18:45, Bron Gondwana wrote: > Cyrus git-master has XMOVE implemented. We use it in FastMail for > our web interface to avoid quota issues when moving messages via > the web interface rather than the old hack of working out the quota, > then temporarily raising the limit, doing the copy+expunge and then > reducing the limit again. I've just added support for UID XMOVE into Trojit=C3=A1; it works fine against FastMail's public servers. Cheers, Jan --=20 Trojita, a fast e-mail client -- http://trojita.flaska.net/ --------------enig545574EB81591BBA9505B439 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.17 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk/GkesACgkQamXfqERyJRcZ/ACghu30shm2IhM3ilRR9VSwtJA3 2owAn1HqrcOIlteEFGn1cn3rihnBpNGP =fcfx -----END PGP SIGNATURE----- --------------enig545574EB81591BBA9505B439-- From tss@iki.fi Wed May 30 14:33:01 2012 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 467AF21F8739 for ; Wed, 30 May 2012 14:33:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.339 X-Spam-Level: X-Spam-Status: No, score=-110.339 tagged_above=-999 required=5 tests=[AWL=0.260, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DAuSgJvgqlIA for ; Wed, 30 May 2012 14:33:00 -0700 (PDT) Received: from dovecot.org (dovecot.org [193.210.130.67]) by ietfa.amsl.com (Postfix) with ESMTP id 292B321F8732 for ; Wed, 30 May 2012 14:33:00 -0700 (PDT) Received: from [192.168.10.101] (a88-112-255-76.elisa-laajakaista.fi [88.112.255.76]) by dovecot.org (Postfix) with ESMTP id 0B6AB1AE876B; Thu, 31 May 2012 00:32:59 +0300 (EEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Timo Sirainen In-Reply-To: Date: Thu, 31 May 2012 00:32:58 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: "Adrien W. de Croy" X-Mailer: Apple Mail (2.1084) Cc: "Discussion on drastically slimming-down IMAP." Subject: Re: [imap5] Should unsolicited EXPUNGE responses be returned during UID MOVE? 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, 30 May 2012 21:33:01 -0000 It's doable of course, but I don't think it's worth the extra complexity = for 1) the protocol specs and 2) client implementations. The bandwidth = savings are pretty minimal. On 31.5.2012, at 0.11, Adrien W. de Croy wrote: > what about using the sequences in the final tagged response as an = indication of what was actually successfully moved.. the ones that map = source messages to new UIDs. > We suppress EXPUNGE responses during MOVE already. When you're moving = a large set of messages, this improves things quite a bit in terms of bw = and speed. >=20 > ---- > Adrien de Croy - WinGate Proxy Server - http://www.wingate.com > WinGate 7 is released! - http://www.wingate.com/getlatest/ >=20 >=20 >=20 > ------ Original Message ------ > From: "Timo Sirainen" > To: "Cyrus Daboo" > Cc: "Discussion on drastically slimming-down IMAP." > Sent: 31/05/2012 5:27:22 a.m. > Subject: Re: [imap5] Should unsolicited EXPUNGE responses be returned = during UID MOVE? >> On 30.5.2012, at 20.20, Cyrus Daboo wrote: >>=20 >>=20 >>>>>=20 >>>>> So Arnt tells me. >>>>>=20 >>>>=20 >>>>=20 >>>> If I can implement it this way without violating the spec: >>>>=20 >>>> 1. Verify that ACLs allow expunge, fail if not >>>> 2. Do atomic UID COPY without enforcing quota limits >>>> 3. Expunge the messages >>>> [4. If expunge for some strange reason fails now, there are = probably >>>> duplicates now. I'm not sure if I want to bother fixing that = situation. >>>> It should "never" happen anyway.] >>>>=20 >>>> then I could add it to Dovecot pretty much immediately. >>>>=20 >>>=20 >>>=20 >>> So if the expunge does fail, how are you going to report that to the = client? Arnt's current spec does not show any * N EXPUNGE responses = coming back, so I am assuming that the client is supposed to implicitly = assume the expunges took place, which would cause a problem if they did = not take place. But that seems wrong to me - shouldn't UID MOVE cause * = N EXPUNGE to be sent for each message that was actually moved? >>>=20 >>=20 >>=20 >> I assumed that this was a bug in the example and was going to report = it as some point. I think the EXPUNGE/VANISHED replies should be sent in = any case, even if MOVE was required to be fully atomic. Otherwise if the = UID MOVE command sends an untagged FETCH/EXPUNGE reply it wouldn't be = obvious if the sequence number referred to the state before or after the = MOVE expunges. >>=20 >> _______________________________________________ >> imap5 mailing list >> imap5@ietf.org >> https://www.ietf.org/mailman/listinfo/imap5 >>=20 >>=20 >=20 > _______________________________________________ > imap5 mailing list > imap5@ietf.org > https://www.ietf.org/mailman/listinfo/imap5 >=20 From arnt@gulbrandsen.priv.no Wed May 30 15:01:03 2012 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 2C06911E80C5 for ; Wed, 30 May 2012 15:01:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.56 X-Spam-Level: X-Spam-Status: No, score=-1.56 tagged_above=-999 required=5 tests=[AWL=-0.296, BAYES_00=-2.599, HTML_MESSAGE=0.001, HTML_TAG_BALANCE_HEAD=1.334] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KWd+AEBNx4EK for ; Wed, 30 May 2012 15:01:02 -0700 (PDT) Received: from strange.aox.org (strange.aox.org [IPv6:2001:4d88:100c::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CEDE11E8087 for ; Wed, 30 May 2012 15:01:02 -0700 (PDT) Received: from fri.gulbrandsen.priv.no (unknown [127.0.0.1]) by strange.aox.org (Postfix) with ESMTP id 6701EF8CE8A; Wed, 30 May 2012 22:01:01 +0000 (UTC) Received: from arnt@gulbrandsen.priv.no by fri.gulbrandsen.priv.no (Archiveopteryx 3.1.4) with esmtpsa id 1338415260-10044-10043/11/3; Wed, 30 May 2012 22:01:00 +0000 User-Agent: Kaiten Mail In-Reply-To: References: <798B43D6C44C87BB95E00D91@caldav.corp.apple.com> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=----U83UR411HAGYAEEDM0530MPO5RS4JM From: Arnt Gulbrandsen Date: Thu, 31 May 2012 00:00:52 +0200 To: Barry Leiba , imap5@ietf.org Message-Id: Subject: Re: [imap5] Proposal for "imapmove" working group 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, 30 May 2012 22:01:03 -0000 ------U83UR411HAGYAEEDM0530MPO5RS4JM Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Earlier tonight I posted a link to a bug report for zarafa and thunderbir= d, showing problems with a proprietary aol extension they both implement. If that does not show real need, I don't know what would suffice. Barry Leiba wrote: >On Wed, May 30, 2012 at 12:22 PM, Cyrus Daboo wrote: > >> Which mailing list? imapext or imap5? > >Typo (or braino). There is no "imapext" list. > >>> flagged for deletion, the third step has the side effect of >expunging >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0^^^ >> >> Really it is "can have the side effect" since clients might have the >option >> of using UID EXPUNGE > >But UID EXPUNGE is part of the UIDPLUS extension, not in base IMAP >(and I'm not sure how widely deployed UIDPLUS is. And, as you say, >one would have to be mentally unstable to try to work around this the >other way. Still, "can have" is fine, and I've changed the text. > >>> The IMAP MOVE extension (imapmove) working group has the single task >>> of developing an atomic IMAP MOVE command that will move a set of >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0^^^^^^ = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ^^^^^^^ >> Use "extension" instead of "command" as the actual command is "UID >MOVE" as >> per Arnt's spec. As per Timo, I am not sure we should state it will >be >> "atomic" as that may restrict what we do in the spec. > >It's meant to be "atomic" from the client's view, whether or not it's >atomic in the server. But I prefer your later suggestion of "single >command", so I've changed it accordingly. > >> Are there existing client and server implementations of the >> draft-gulbrandsen-imap-move right now? > >So Arnt tells me. > >> Does "implementation" also cover >> actual interoperability testing, or does it only speak to the actual >ability >> to modify existing servers/clients to adopt the extension? > >If there's interop testing, it would be very fine to document that >here. But that's not what this is about; this is to show that there's >a real need for this, and active work on implementations (as opposed >to our developing another IMAP extension that gets essentially no >use). > >Attached is the latest charter version, with these changes. > >Barry > > >------------------------------------------------------------------------ > >_______________________________________________ >imap5 mailing list >imap5@ietf.org >https://www.ietf.org/mailman/listinfo/imap5 Arnt ------U83UR411HAGYAEEDM0530MPO5RS4JM Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable Earlier tonight I posted a = link to a bug report for zarafa and thunderbird, showing problems with a = proprietary aol extension they both implement.

If that does not show real need, I don't know what would suffice.


Barry Leiba <barryleiba@computer.or= g> wrote:
On Wed, May 30, 2012 at 12:22 PM, Cyrus =
Daboo <cyrus@daboo.name> wrote:

Which mailing list? imapext or imap5?
Typo (or braino).  There is no "imapext" list.

flagged for deletion, the third step has =
the side effect of expunging
=C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0^^^

Really it is =
"can have the side effect" since clients might have the option
of =
using UID EXPUNGE

But UID EXPUNGE is part of the =
UIDPLUS extension, not in base
IMAP
(and I'm not sure how widely deployed UIDPLUS is.  And, as you =
say,
one would have to be mentally unstable to try to work around =
this the
other way.  Still, "can have" is fine, and I've changed =
the text.

The IMAP MOVE =
extension (imapmove) working group has the single task
of developing=
 an atomic IMAP MOVE command that will move a set of
=C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0^^^^^^ =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 ^^^^^^^
Use "extension" instead of =
"command" as the actual command is "UID MOVE" as
per Arnt's spec. =
As per Timo, I am not sure we should state it will be
"atomic" as =
that may restrict what we do in the spec.

It's meant =
to be "atomic" from the client's view, whether or not it's
atomic in the server.  But I prefer your later suggestion of "singlecommand", so I've changed it accordingly.

Are there existing client and =
server implementations of the
draft-gulbrandsen-imap-move right =
now?

So Arnt tells me.

Does "implementation" also cover
actual interoperability testing, or does it only speak to the actual =
ability
to modify existing servers/clients to adopt the extension?
If there's interop testing, it would be very fine to =
document that
here.  But that's not what this is about; this is to =
show that there's
a real need for this, and active work on implement=
ations (as opposed
to our developing another IMAP extension that =
gets essentially
no
use).

Attached is the latest charter version, with =
these changes.

Barry


imap5 mailing list
imap5@ie=
tf.org
https=
://www.ietf.org/mailman/listinfo/imap5
=
Arnt ------U83UR411HAGYAEEDM0530MPO5RS4JM-- From adrien@qbik.com Wed May 30 16:07:32 2012 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 199C011E8114 for ; Wed, 30 May 2012 16:07:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599, SUBJ_RE_NUM=1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iPs0DSr7tDtk for ; Wed, 30 May 2012 16:07:31 -0700 (PDT) Received: from smtp.qbik.com (smtp.qbik.com [210.55.214.35]) by ietfa.amsl.com (Postfix) with ESMTP id 12AC321F8615 for ; Wed, 30 May 2012 16:07:30 -0700 (PDT) Received: From [192.168.0.10] (unverified [192.168.0.10]) by SMTP Server [192.168.0.1] (WinGate SMTP Receiver v7.2.1 (Build 3414)) with SMTP id <0019054006@smtp.qbik.com>; Thu, 31 May 2012 11:07:29 +1200 From: "Adrien W. de Croy" To: "Timo Sirainen" Date: Wed, 30 May 2012 23:07:29 +0000 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; format=flowed; charset=utf-8 In-Reply-To: Message-Id: Mime-Version: 1.0 User-Agent: eM_Client/4.0.14522.0 Cc: "Discussion on drastically slimming-down IMAP." Subject: Re: [imap5] Should unsolicited EXPUNGE responses be returned during UID MOVE? X-BeenThere: imap5@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: "Adrien W. de Croy" List-Id: "Discussion on drastically slimming-down IMAP." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 May 2012 23:07:32 -0000 ------ Original Message ------ From: "Timo Sirainen" To: "Adrien W. de Croy" Cc: "Cyrus Daboo" ;"Discussion on drastically slimming-down IMAP." Sent: 31/05/2012 9:32:58 a.m. Subject: Re: [imap5] Should unsolicited EXPUNGE responses be returned during UID MOVE? >It's doable of course, but I don't think it's worth the extra complexity f= or 1) the protocol specs and 2) client implementations. The bandwidth savin= gs are pretty minimal. > I thought it was already there. > > >On 31.5.2012, at 0.11, Adrien W. de Croy wrote: > > >> >>what about using the sequences in the final tagged response as an indicat= ion of what was actually successfully moved.. the ones that map source mes= sages to new UIDs. >>We suppress EXPUNGE responses during MOVE already. When you're moving a = large set of messages, this improves things quite a bit in terms of bw and = speed. >> >>---- >>Adrien de Croy - WinGate Proxy Server - http://www.wingate.com >>WinGate 7 is released! - http://www.wingate.com/getlatest/ >> >> >> >>------ Original Message ------ >>From: "Timo Sirainen" >>To: "Cyrus Daboo" >>Cc: "Discussion on drastically slimming-down IMAP." >>Sent: 31/05/2012 5:27:22 a.m. >>Subject: Re: [imap5] Should unsolicited EXPUNGE responses be returned dur= ing UID MOVE? >> >>> >>>On 30.5.2012, at 20.20, Cyrus Daboo wrote: >>> >>> >>> >>>>>> >>>>>> >>>>>>So Arnt tells me. >>>>>> >>>>>> >>>>> >>>>> >>>>> >>>>>If I can implement it this way without violating the spec: >>>>> >>>>>1. Verify that ACLs allow expunge, fail if not >>>>>2. Do atomic UID COPY without enforcing quota limits >>>>>3. Expunge the messages >>>>>[4. If expunge for some strange reason fails now, there are probably= >>>>>duplicates now. I'm not sure if I want to bother fixing that situation= . >>>>>It should "never" happen anyway.] >>>>> >>>>>then I could add it to Dovecot pretty much immediately. >>>>> >>>>> >>>> >>>> >>>> >>>>So if the expunge does fail, how are you going to report that to the cl= ient? Arnt's current spec does not show any * N EXPUNGE responses coming ba= ck, so I am assuming that the client is supposed to implicitly assume the e= xpunges took place, which would cause a problem if they did not take place.= But that seems wrong to me - shouldn't UID MOVE cause * N EXPUNGE to be se= nt for each message that was actually moved? >>>> >>>> >>> >>> >>> >>>I assumed that this was a bug in the example and was going to report it = as some point. I think the EXPUNGE/VANISHED replies should be sent in any c= ase, even if MOVE was required to be fully atomic. Otherwise if the UID MOV= E command sends an untagged FETCH/EXPUNGE reply it wouldn't be obvious if t= he sequence number referred to the state before or after the MOVE expunges.= >>> >>>_______________________________________________ >>>imap5 mailing list >>>imap5@ietf.org >>>https://www.ietf.org/mailman/listinfo/imap5 >>> >>> >>> >> >> >>_______________________________________________ >>imap5 mailing list >>imap5@ietf.org >>https://www.ietf.org/mailman/listinfo/imap5 >> >> > From tss@iki.fi Wed May 30 16:35:03 2012 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 C4EA611E80EC for ; Wed, 30 May 2012 16:35:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.391 X-Spam-Level: X-Spam-Status: No, score=-110.391 tagged_above=-999 required=5 tests=[AWL=0.208, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q3Y5X6W8zoKL for ; Wed, 30 May 2012 16:35:03 -0700 (PDT) Received: from dovecot.org (dovecot.org [193.210.130.67]) by ietfa.amsl.com (Postfix) with ESMTP id 2F58611E80D5 for ; Wed, 30 May 2012 16:35:03 -0700 (PDT) Received: from [192.168.10.101] (a88-112-255-76.elisa-laajakaista.fi [88.112.255.76]) by dovecot.org (Postfix) with ESMTP id 52A711AE876B; Thu, 31 May 2012 02:35:02 +0300 (EEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Timo Sirainen In-Reply-To: Date: Thu, 31 May 2012 02:35:03 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: "Adrien W. de Croy" X-Mailer: Apple Mail (2.1084) Cc: "Discussion on drastically slimming-down IMAP." Subject: Re: [imap5] Should unsolicited EXPUNGE responses be returned during UID MOVE? 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, 30 May 2012 23:35:03 -0000 On 31.5.2012, at 2.07, Adrien W. de Croy wrote: >>> what about using the sequences in the final tagged response as an = indication of what was actually successfully moved.. the ones that map = source messages to new UIDs. >>> We suppress EXPUNGE responses during MOVE already. When you're = moving a large set of messages, this improves things quite a bit in = terms of bw and speed. >> It's doable of course, but I don't think it's worth the extra = complexity for 1) the protocol specs and 2) client implementations. The = bandwidth savings are pretty minimal. >>=20 > I thought it was already there. The COPYUIDs may or may not be there depending on UIDPLUS extension, but = what isn't there is the requirement for clients to parse the UIDs and = apply them internally as equivalent to EXPUNGEd UIDs. I see tons of = problems with that. Probably nothing that couldn't be overcome by adding = a lot of restrictions to the spec and to the client behavior, but it's = really not worth the extra complexity. From adrien@qbik.com Wed May 30 17:05:28 2012 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 9AA7311E80D5 for ; Wed, 30 May 2012 17:05:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.932 X-Spam-Level: X-Spam-Status: No, score=-1.932 tagged_above=-999 required=5 tests=[AWL=-0.333, BAYES_00=-2.599, SUBJ_RE_NUM=1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HzIzAglZ5ZgR for ; Wed, 30 May 2012 17:05:27 -0700 (PDT) Received: from smtp.qbik.com (smtp.qbik.com [210.55.214.35]) by ietfa.amsl.com (Postfix) with ESMTP id 455AE11E8116 for ; Wed, 30 May 2012 17:05:27 -0700 (PDT) Received: From [192.168.0.10] (unverified [192.168.0.10]) by SMTP Server [192.168.0.1] (WinGate SMTP Receiver v7.2.1 (Build 3414)) with SMTP id <0019054074@smtp.qbik.com>; Thu, 31 May 2012 12:05:25 +1200 From: "Adrien W. de Croy" To: "Timo Sirainen" Date: Thu, 31 May 2012 00:05:25 +0000 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; format=flowed; charset=utf-8 In-Reply-To: Message-Id: Mime-Version: 1.0 User-Agent: eM_Client/4.0.14522.0 Cc: "Discussion on drastically slimming-down IMAP." Subject: Re: [imap5] Should unsolicited EXPUNGE responses be returned during UID MOVE? X-BeenThere: imap5@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: "Adrien W. de Croy" List-Id: "Discussion on drastically slimming-down IMAP." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 May 2012 00:05:28 -0000 problem is that to convert back to msgno for an expunge response requires a lock on the source. COMPRESS can take the pain out of the actual protocol transmission. Maybe require VANISHED responses instead. ------ Original Message ------ From: "Timo Sirainen" To: "Adrien W. de Croy" Cc: "Discussion on drastically slimming-down IMAP." Sent: 31/05/2012 11:35:03 a.m. Subject: Re: Re[2]: [imap5] Should unsolicited EXPUNGE responses be returned during UID MOVE? >On 31.5.2012, at 2.07, Adrien W. de Croy wrote: > > >>>> >>>>what about using the sequences in the final tagged response as an indic= ation of what was actually successfully moved.. the ones that map source m= essages to new UIDs. >>>>We suppress EXPUNGE responses during MOVE already. When you're moving = a large set of messages, this improves things quite a bit in terms of bw an= d speed. >>>> >>> >>>It's doable of course, but I don't think it's worth the extra complexity= for 1) the protocol specs and 2) client implementations. The bandwidth sav= ings are pretty minimal. >>> >>> >> >>I thought it was already there. >> > > > >The COPYUIDs may or may not be there depending on UIDPLUS extension, but w= hat isn't there is the requirement for clients to parse the UIDs and apply = them internally as equivalent to EXPUNGEd UIDs. I see tons of problems with= that. Probably nothing that couldn't be overcome by adding a lot of restri= ctions to the spec and to the client behavior, but it's really not worth th= e extra complexity. > > > From brong@fastmail.fm Thu May 31 01:43:03 2012 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 E57AE21F86BD for ; Thu, 31 May 2012 01:43:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IfBL4Ohs2PJF for ; Thu, 31 May 2012 01:43:03 -0700 (PDT) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) by ietfa.amsl.com (Postfix) with ESMTP id 0D13321F8644 for ; Thu, 31 May 2012 01:43:02 -0700 (PDT) Received: from compute2.internal (compute2.nyi.mail.srv.osa [10.202.2.42]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id 19C46213AD; Thu, 31 May 2012 04:42:59 -0400 (EDT) Received: from web1.nyi.mail.srv.osa ([10.202.2.211]) by compute2.internal (MEProxy); Thu, 31 May 2012 04:43:00 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=fastmail.fm; h= message-id:from:to:cc:mime-version:content-transfer-encoding :content-type:subject:date:in-reply-to:references; s=mesmtp; bh= CMDCgrI9X2cB7bpqGu62Rckns98=; b=EAcGWpCfb7DsFTqQMVAoCdwLYX+cYG6q Q1Z4o++t6tGFi3uzJqjTQQlydiUDiaVUPgAyd4dxDnSOmqfjmrwIUCVh1hqJDVbH PVC41iNwwRaYRdVHWLJzfxkr+R8ZadI7hVA72pNaVi+S2so+q1P3X69iah96crKj QwTzCUYnEuU= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=message-id:from:to:cc:mime-version :content-transfer-encoding:content-type:subject:date:in-reply-to :references; s=smtpout; bh=CMDCgrI9X2cB7bpqGu62Rckns98=; b=puo/t rXk76MQh6B8pYesUcSwBxMCovOXe+VWSZYyCMoVma1DMkYM7++/0Z8fzNM0GwLIv WGSH4rJtBYZzKu8qnlM8SS/jX8jkhhi3YGcR9FKuSe+U8dwWq55DsIKy4ftpc0wE B9UESQrSnL7Vq+WcjkdHqgzWo8IQcK6HjRpWrM= Received: by web1.nyi.mail.srv.osa (Postfix, from userid 99) id 55E5EA0007D; Thu, 31 May 2012 04:42:59 -0400 (EDT) Message-Id: <1338453779.23343.140661083095925.4E6CADFD@webmail.messagingengine.com> X-Sasl-Enc: Mvdts+AA8wm7j8nLWQaw2WiGtkpBOcgJ9dISjBYg3Q/M 1338453779 From: Bron Gondwana To: "Adrien W. de Croy" , Timo Sirainen MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain X-Mailer: MessagingEngine.com Webmail Interface Date: Thu, 31 May 2012 10:42:59 +0200 In-Reply-To: References: Cc: "Discussion on drastically slimming-down IMAP." Subject: Re: [imap5] Should unsolicited EXPUNGE responses be returned during UID MOVE? 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: Thu, 31 May 2012 08:43:04 -0000 On Thu, May 31, 2012, at 12:05 AM, Adrien W. de Croy wrote: > problem is that to convert back to msgno for an expunge response > requires a lock on the source. Depends if you cache them or not. Since msgno is per-connection, it doesn't matter if they've changed in other sessions meanwhile. > COMPRESS can take the pain out of the actual protocol transmission. > > Maybe require VANISHED responses instead. If you want VANISHED responses you can ENABLE QRESYNC. I see no reason not to spit regular EXPUNGED responses otherwise. The clients that know how to handle VANISHED can just turn on QRESYNC, the others won't have to deal with it. Bron. -- Bron Gondwana brong@fastmail.fm From jkt@flaska.net Thu May 31 02:41:47 2012 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 B55DE21F8690 for ; Thu, 31 May 2012 02:41:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.65 X-Spam-Level: X-Spam-Status: No, score=-0.65 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YwE7qFVXyCFz for ; Thu, 31 May 2012 02:41:47 -0700 (PDT) Received: from serv132.fzu.cz (serv132.fzu.cz [147.231.26.132]) by ietfa.amsl.com (Postfix) with ESMTP id D02A521F85C4 for ; Thu, 31 May 2012 02:41:46 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAAk8x0+T5xpZ/2dsb2JhbABEhU6uPYEHghgBAQUjVRELGAkWCwICCQMCAQIBRRMIAQGIB6YvklyLKgGEGoESA441gR2FRoEPjmSCYoFd X-IronPort-AV: E=Sophos;i="4.75,691,1330902000"; d="asc'?scan'208";a="6055242" Received: from freja.fzu.cz ([147.231.26.89]) by serv147.fzu.cz with ESMTP; 31 May 2012 11:41:44 +0200 Received: from svist.flaska.net (pc069c.fzu.cz [147.231.27.69]) by freja.fzu.cz (Postfix) with ESMTPSA id E709D3DA82 for ; Thu, 31 May 2012 11:41:43 +0200 (CEST) Message-ID: <4FC73CD8.2060009@flaska.net> Date: Thu, 31 May 2012 11:41:44 +0200 From: =?UTF-8?B?SmFuIEt1bmRyw6F0?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.3) Gecko/20120306 Thunderbird/10.0.3 MIME-Version: 1.0 To: imap5@ietf.org References: <1338453779.23343.140661083095925.4E6CADFD@webmail.messagingengine.com> In-Reply-To: <1338453779.23343.140661083095925.4E6CADFD@webmail.messagingengine.com> X-Enigmail-Version: 1.4 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig913EA29A428B21AEA7C0258A" Subject: Re: [imap5] Should unsolicited EXPUNGE responses be returned during UID MOVE? 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: Thu, 31 May 2012 09:41:47 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig913EA29A428B21AEA7C0258A Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 05/31/12 10:42, Bron Gondwana wrote: > If you want VANISHED responses you can ENABLE QRESYNC. I see no reason= > not to spit regular EXPUNGED responses otherwise. The clients that kno= w > how to handle VANISHED can just turn on QRESYNC, the others won't have = to > deal with it. As a client writer, I'd expect the UID MOVE to return either explicit EXPUNGE or explicit VANISHED messages. I do see that omitting that leads to slightly bigger bandwidth usage (easily mitigated by VANISHED), but such a behavior would surprise me, based on the way how the rest of the IMAP works. In my opinion, section 3 of the draft shall read: 3. UID MOVE Command ***** I'm adding explicit info about the responses here ***** Arguments: message set, mailbox name Data: untagged responses: EXPUNGE or VANISHED Result: OK - at least one message has been moved NO - none of the messages were moved BAD - command unknown or arguments invalid ***** The following remains the same from the 01 draft ***** The UID MOVE command takes two arguments: a set of UIDs and a named mailbox. It moves each message indicated by UID set to the named mailbox.= The UID MOVE command is the same as a sequence of UID COPY, UID STORE +FLAGS \DELETED and UID EXPUNGE, with two added requirements: First, each message SHOULD either be moved or unaffected. The server SHOULD NOT leave a message in neither or both mailboxes afterwards (even if the server returns a tagged NO response). Second, the messages MUST NOT have the \Deleted flag set in the target mailbox. ***** And here are some additions ****** If at least one message was successfully moved to the target mailbox, the command MUST report success with a tagged OK response. If none of the messages could be moved, the server MUST respond with a tagged NO. Clients are informed about the fate of the individual messages through regular untagged EXPUNGE responses, as defined in RFC 3501. In case the current session has enabled the QRESYNC extension, untagged VANISHED shall be send instead of the EXPUNGE responses. ***** The example is also modified with EXPUNGEs and the number of messages is reduced ******* An example: C: a UID MOVE 42:45 forble S: * 15 EXPUNGE S: * 15 EXPUNGE S: * 15 EXPUNGE S: * 15 EXPUNGE S: a OK [COPYUID 432432 1202:1205] Done ****** End ****** I see a few issues to be discussed, though: - There's a requirement that a message in the target mailbox must not have the \Deleted flag. What is supposed to happen when I UID MOVE a message which was already marked as \Deleted before? - Sending the untagged EXPUNGE/VANISHED and only after them the COPYUID might be troublesome for some clients -- for example, my code will react to EXPUNGE by removing the cached data for that message from the on-disk cache. When the COPYUID arrives, the data is already gone. (My code actually ignores COPYUID for now anyway, but that's not relevant here.) - Postponing of the untagged EXPUNGE/VANISHED until after the tagged OK is probably a bad idea, so what about a special "VANISHED (MOVED)" which would hint the client that the data shall not be purged immediately? - Section 4.3 shall probably say that servers supporting the UIDPLUS extension SHOULD include the COPYUID response code in the tagged OK, but that means that the introduction in section 4 shall not claim that there are no requirements in that section. Cheers, Jan --=20 Trojita, a fast e-mail client -- http://trojita.flaska.net/ --------------enig913EA29A428B21AEA7C0258A 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.17 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk/HPNgACgkQamXfqERyJRerPQCfbOQPvavf01tIlZvlmcc1u2+S 2EsAnRG4LV/SWp17jIL/JL0p/KieZq1X =okvr -----END PGP SIGNATURE----- --------------enig913EA29A428B21AEA7C0258A-- From tss@iki.fi Thu May 31 02:52:10 2012 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 BCB1921F8630 for ; Thu, 31 May 2012 02:52:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.299 X-Spam-Level: X-Spam-Status: No, score=-110.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FnK89GwYbvZK for ; Thu, 31 May 2012 02:52:10 -0700 (PDT) Received: from dovecot.org (dovecot.org [193.210.130.67]) by ietfa.amsl.com (Postfix) with ESMTP id 1C17B21F85C4 for ; Thu, 31 May 2012 02:52:10 -0700 (PDT) Received: from [10.217.1.201] (unknown [193.184.212.30]) by dovecot.org (Postfix) with ESMTP id D70DE1AE8769; Thu, 31 May 2012 12:52:08 +0300 (EEST) Message-ID: <1338457927.4384.183.camel@innu> From: Timo Sirainen To: Jan =?ISO-8859-1?Q?Kundr=E1t?= Date: Thu, 31 May 2012 12:52:07 +0300 In-Reply-To: <4FC73CD8.2060009@flaska.net> References: <1338453779.23343.140661083095925.4E6CADFD@webmail.messagingengine.com> <4FC73CD8.2060009@flaska.net> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.2.3-0ubuntu6 Content-Transfer-Encoding: 8bit Mime-Version: 1.0 Cc: imap5@ietf.org Subject: Re: [imap5] Should unsolicited EXPUNGE responses be returned during UID MOVE? 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: Thu, 31 May 2012 09:52:10 -0000 On Thu, 2012-05-31 at 11:41 +0200, Jan Kundrát wrote: > - Sending the untagged EXPUNGE/VANISHED and only after them the COPYUID > might be troublesome for some clients -- for example, my code will react > to EXPUNGE by removing the cached data for that message from the on-disk > cache. When the COPYUID arrives, the data is already gone. (My code > actually ignores COPYUID for now anyway, but that's not relevant here.) > > - Postponing of the untagged EXPUNGE/VANISHED until after the tagged OK > is probably a bad idea, so what about a special "VANISHED (MOVED)" which > would hint the client that the data shall not be purged immediately? Another possibility: C: a UID MOVE 42:45 forble S: * OK [COPYUID 432432 1202:1205] Messages moved S: * 15 EXPUNGE S: * 15 EXPUNGE S: * 15 EXPUNGE S: * 15 EXPUNGE S: a OK Done From jkt@flaska.net Thu May 31 03:11:39 2012 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 7A05B21F853C for ; Thu, 31 May 2012 03:11:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.8 X-Spam-Level: X-Spam-Status: No, score=-0.8 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5GlRRgY-UejA for ; Thu, 31 May 2012 03:11:38 -0700 (PDT) Received: from serv132.fzu.cz (serv132.fzu.cz [147.231.26.132]) by ietfa.amsl.com (Postfix) with ESMTP id 466FB21F8460 for ; Thu, 31 May 2012 03:11:36 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAFZDx0+T5xpZ/2dsb2JhbABEhU6uPYEHghgBAQUjVRELGAkWCwICCQMCAQIBRRMIAQGIB6Y1klWLK4IWggSBEgOONYEdhUaBD45kgmKBXQ X-IronPort-AV: E=Sophos;i="4.75,691,1330902000"; d="asc'?scan'208";a="6055922" Received: from freja.fzu.cz ([147.231.26.89]) by serv147.fzu.cz with ESMTP; 31 May 2012 12:11:35 +0200 Received: from svist.flaska.net (pc069c.fzu.cz [147.231.27.69]) by freja.fzu.cz (Postfix) with ESMTPSA id 146DB3DA82 for ; Thu, 31 May 2012 12:11:35 +0200 (CEST) Message-ID: <4FC743D7.1010603@flaska.net> Date: Thu, 31 May 2012 12:11:35 +0200 From: =?UTF-8?B?SmFuIEt1bmRyw6F0?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.3) Gecko/20120306 Thunderbird/10.0.3 MIME-Version: 1.0 To: imap5@ietf.org References: <1338453779.23343.140661083095925.4E6CADFD@webmail.messagingengine.com> <4FC73CD8.2060009@flaska.net> <1338457927.4384.183.camel@innu> In-Reply-To: <1338457927.4384.183.camel@innu> X-Enigmail-Version: 1.4 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig089319EBDBD3EC99C76A46FA" Subject: Re: [imap5] Should unsolicited EXPUNGE responses be returned during UID MOVE? 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: Thu, 31 May 2012 10:11:39 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig089319EBDBD3EC99C76A46FA Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 05/31/12 11:52, Timo Sirainen wrote: > Another possibility: >=20 > C: a UID MOVE 42:45 forble > S: * OK [COPYUID 432432 1202:1205] Messages moved > S: * 15 EXPUNGE > S: * 15 EXPUNGE > S: * 15 EXPUNGE > S: * 15 EXPUNGE > S: a OK Done The untagged OK with COPYUID doesn't specify to which UID MOVE it is related, unfortunately, and will therefore break with concurrent UID MOVE operations. My GUI will happily send concurrent UID MOVEs when the connection is slow and user moves her mouse fast enough, so I believe it's a real problem. I'm not aware of any extension using multiple response codes at once (and hence "* OK [TAG a COPYUID 432432 1202:1205] Messages moved" is not really a COPYUID anymore), what about a special MOVEUID response code? * OK [MOVEUID a 432432 1202:1205] Messages moved I like that, and it also means that my proposed "VANISHED (MOVED)" is not necessary. And to reduce the number of possible combinations, what about making the MOVEUID a mandatory response, no matter whether UIDPLUS is supported? Cheers, Jan --=20 Trojita, a fast e-mail client -- http://trojita.flaska.net/ --------------enig089319EBDBD3EC99C76A46FA 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.17 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk/HQ9cACgkQamXfqERyJRe8UwCfRYF28uEyWL8qAfK18yxyPKup vHcAnjBvjsGwb36cI8BI+YNp3SZbhjmU =Opks -----END PGP SIGNATURE----- --------------enig089319EBDBD3EC99C76A46FA-- From adrien@qbik.com Thu May 31 03:42:35 2012 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 18F5621F8658 for ; Thu, 31 May 2012 03:42:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.199 X-Spam-Level: X-Spam-Status: No, score=-2.199 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q24GNn1pstFg for ; Thu, 31 May 2012 03:42:34 -0700 (PDT) Received: from smtp.qbik.com (smtp.qbik.com [210.55.214.35]) by ietfa.amsl.com (Postfix) with ESMTP id CB2B821F85C4 for ; Thu, 31 May 2012 03:42:33 -0700 (PDT) Received: From [192.168.1.10] (unverified [219.89.218.74]) by SMTP Server [210.55.214.35] (WinGate SMTP Receiver v7.2.2 (Build 3416)) with SMTP id <0019054899@smtp.qbik.com>; Thu, 31 May 2012 22:42:31 +1200 From: "Adrien W. de Croy" To: "Timo Sirainen" , =?utf-8?q?Jan=20Kundr=c3=a1t?= Date: Thu, 31 May 2012 10:42:20 +0000 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; format=flowed; charset=utf-8 In-Reply-To: <1338457927.4384.183.camel@innu> Message-Id: Mime-Version: 1.0 User-Agent: eM_Client/4.0.14522.0 Cc: "imap5@ietf.org" Subject: Re: [imap5] Should unsolicited EXPUNGE responses be returned during UID MOVE? X-BeenThere: imap5@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: "Adrien W. de Croy" List-Id: "Discussion on drastically slimming-down IMAP." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 May 2012 10:42:35 -0000 =EF=BB=BF well one thing to think about. Since there are already servers and clients deployed, unless we allow there to be some way to distinguish between a MOVE extension that sends = EXPUNGES and one (legacy) that doesn't, do we need to call this MOVE2? Adrien ---- Adrien de Croy - WinGate Proxy Server - http://www.wingate.com WinGate 7 is released! - http://www.wingate.com/getlatest/ ------ Original Message ------ From: "Timo Sirainen" To: "Jan Kundr=C3=A1t" Cc: "imap5@ietf.org" Sent: 31/05/2012 9:52:07 p.m. Subject: Re: [imap5] Should unsolicited EXPUNGE responses be returned during UID MOVE? >On Thu, 2012-05-31 at 11:41 +0200, Jan Kundr=C3=A1t wrote: > >> >>- Sending the untagged EXPUNGE/VANISHED and only after them the COPYUID= >>might be troublesome for some clients -- for example, my code will react= >>to EXPUNGE by removing the cached data for that message from the on-disk= >>cache. When the COPYUID arrives, the data is already gone. (My code >>actually ignores COPYUID for now anyway, but that's not relevant here.)= >> >>- Postponing of the untagged EXPUNGE/VANISHED until after the tagged OK= >>is probably a bad idea, so what about a special "VANISHED (MOVED)" which= >>would hint the client that the data shall not be purged immediately? >> > > >Another possibility: > > C: a UID MOVE 42:45 forble > S: * OK [COPYUID 432432 1202:1205] Messages moved > S: * 15 EXPUNGE > S: * 15 EXPUNGE > S: * 15 EXPUNGE > S: * 15 EXPUNGE > S: a OK Done > > >_______________________________________________ >imap5 mailing list >imap5@ietf.org >https://www.ietf.org/mailman/listinfo/imap5 > > From arnt@gulbrandsen.priv.no Thu May 31 05:12:27 2012 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 6FB3221F865A for ; Thu, 31 May 2012 05:12:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.129 X-Spam-Level: X-Spam-Status: No, score=-2.129 tagged_above=-999 required=5 tests=[AWL=0.470, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t7FA520D8CUz for ; Thu, 31 May 2012 05:12:27 -0700 (PDT) Received: from strange.aox.org (strange.aox.org [IPv6:2001:4d88:100c::1]) by ietfa.amsl.com (Postfix) with ESMTP id DE22421F8658 for ; Thu, 31 May 2012 05:12:26 -0700 (PDT) Received: from fri.gulbrandsen.priv.no (unknown [127.0.0.1]) by strange.aox.org (Postfix) with ESMTP id 30257F8CB15; Thu, 31 May 2012 12:12:25 +0000 (UTC) Received: from arnt@gulbrandsen.priv.no by fri.gulbrandsen.priv.no (Archiveopteryx 3.1.4) with esmtpsa id 1338466344-10044-10043/11/4; Thu, 31 May 2012 12:12:24 +0000 Message-Id: <4FC76025.1020508@gulbrandsen.priv.no> Date: Thu, 31 May 2012 14:12:21 +0200 From: Arnt Gulbrandsen User-Agent: Mozilla/5.0 (X11; Linux i686; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 Mime-Version: 1.0 To: imap5@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=iso-8859-1; format=flowed Subject: Re: [imap5] Should unsolicited EXPUNGE responses be returned during UID MOVE? 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: Thu, 31 May 2012 12:12:27 -0000 On 05/30/2012 07:20 PM, Cyrus Daboo wrote: > Arnt's current spec does not show any * N EXPUNGE responses coming back, > so I am assuming that the client is supposed to implicitly assume the > expunges took place, which would cause a problem if they did not take > place. But that seems wrong to me - shouldn't UID MOVE cause * N EXPUNGE > to be sent for each message that was actually moved? My FUBAR. I'll correct and repost. (My code might actually send EXPUNGE a few instants later. I think that's okay, so long as both server and client change their MSN maps in sync.) Arnt From barryleiba.mailing.lists@gmail.com Thu May 31 07:10:52 2012 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 D9F3821F8673 for ; Thu, 31 May 2012 07:10:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.028 X-Spam-Level: X-Spam-Status: No, score=-103.028 tagged_above=-999 required=5 tests=[AWL=-0.051, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QlnZUYRZAT8G for ; Thu, 31 May 2012 07:10:52 -0700 (PDT) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 0011421F866B for ; Thu, 31 May 2012 07:10:51 -0700 (PDT) Received: by lagv3 with SMTP id v3so803331lag.31 for ; Thu, 31 May 2012 07:10:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type :content-transfer-encoding; bh=D0nLmF6BAvMajRDIL9vhsoz9+tBCiWu+dKrwp5MWq/o=; b=Jqh3zoYLiV2H12I+5EK9r8UgQXVHDG18q5j0VjkY7C3amFY6kaYToSOLzOf7FlQDKQ 8LIoJni0g5UgzLOZsrMRnhjb+qHDavf5MwXqFKy4Pfs2rJZrsOH6f7+zUwXex8EmbYqS sfq0jpho06KtniM0vOv+wg8O/X0TUhEGPBOtTuG//mE1uK1hSy8IMvo05GOBRB1bHxzu niQeTzrERRY912ylnF1qPCpXMEx7xrsNwNVCp+Yng52duCO8PBp1I4oChA6d0idsTy9B 4ARIxpBYhC6XbJn+Ik6h6R4IcEwk9AsQf5kTaqMrpTiRpe6RiOdcOZM02FcGZVyWp/9/ sE1g== MIME-Version: 1.0 Received: by 10.152.111.200 with SMTP id ik8mr19991021lab.15.1338473450860; Thu, 31 May 2012 07:10:50 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.112.48.104 with HTTP; Thu, 31 May 2012 07:10:50 -0700 (PDT) In-Reply-To: References: <798B43D6C44C87BB95E00D91@caldav.corp.apple.com> <45BC9626193BD507CCDBB02D@caldav.corp.apple.com> Date: Thu, 31 May 2012 10:10:50 -0400 X-Google-Sender-Auth: bGOE3O-_J3HXlVmqydGgqHl0lA4 Message-ID: From: Barry Leiba To: imap5@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [imap5] Proposal for "imapmove" working group 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: Thu, 31 May 2012 14:10:53 -0000 > The IESG very strongly wants to use mailing lists at ietf.org, unless > there's a very good reason not to. =A0We could create a new > list, or use the not-very-active imap5 list for a > few months. =A0The latter seemed better to me, since many of the people > who will want to follow this are already there. > > I'm happy to instead create a new list, if consensus goes that way. After some off-list discussion, I think we WILL create a new list, . If anyone *objects* to this, please post here and say why. Otherwise, the next version of the charter proposal will say that. Barry From tss@iki.fi Thu May 31 07:18:31 2012 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 DA07F21F86C3 for ; Thu, 31 May 2012 07:18:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.449 X-Spam-Level: X-Spam-Status: No, score=-110.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UrpRzIYL9rZ7 for ; Thu, 31 May 2012 07:18:31 -0700 (PDT) Received: from dovecot.org (dovecot.org [193.210.130.67]) by ietfa.amsl.com (Postfix) with ESMTP id 4451221F86C2 for ; Thu, 31 May 2012 07:18:31 -0700 (PDT) Received: from [10.217.1.201] (unknown [193.184.212.30]) by dovecot.org (Postfix) with ESMTP id 1B47C1AE87C5 for ; Thu, 31 May 2012 17:18:30 +0300 (EEST) Message-ID: <1338473909.19584.15.camel@innu> From: Timo Sirainen To: imap5@ietf.org Date: Thu, 31 May 2012 17:18:29 +0300 In-Reply-To: References: <798B43D6C44C87BB95E00D91@caldav.corp.apple.com> <45BC9626193BD507CCDBB02D@caldav.corp.apple.com> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.2.3-0ubuntu6 Content-Transfer-Encoding: 7bit Mime-Version: 1.0 Subject: Re: [imap5] Proposal for "imapmove" working group 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: Thu, 31 May 2012 14:18:32 -0000 On Thu, 2012-05-31 at 10:10 -0400, Barry Leiba wrote: > > The IESG very strongly wants to use mailing lists at ietf.org, unless > > there's a very good reason not to. We could create a new > > list, or use the not-very-active imap5 list for a > > few months. The latter seemed better to me, since many of the people > > who will want to follow this are already there. > > > > I'm happy to instead create a new list, if consensus goes that way. > > After some off-list discussion, I think we WILL create a new list, > . If anyone *objects* to this, please post here > and say why. Otherwise, the next version of the charter proposal will > say that. I'm not highly against it, but I think we already have too many imap-related mailing lists. Gets difficult to know sometimes where to post a question and if all the important people are reading the right lists. From cyrus@daboo.name Thu May 31 07:20:21 2012 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 9C9CE21F85A4 for ; Thu, 31 May 2012 07:20:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.901 X-Spam-Level: X-Spam-Status: No, score=-101.901 tagged_above=-999 required=5 tests=[AWL=-0.698, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2ITOQYAJz8KZ for ; Thu, 31 May 2012 07:20:21 -0700 (PDT) Received: from daboo.name (daboo.name [173.13.55.49]) by ietfa.amsl.com (Postfix) with ESMTP id 14AD321F8598 for ; Thu, 31 May 2012 07:20:21 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by daboo.name (Postfix) with ESMTP id 905302841707 for ; Thu, 31 May 2012 10:20:20 -0400 (EDT) X-Virus-Scanned: amavisd-new at daboo.name Received: from daboo.name ([127.0.0.1]) by localhost (daboo.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XyP6gqg1aWIQ for ; Thu, 31 May 2012 10:20:16 -0400 (EDT) Received: from caldav.corp.apple.com (unknown [17.45.162.46]) by daboo.name (Postfix) with ESMTPSA id C347D28416FA for ; Thu, 31 May 2012 10:20:15 -0400 (EDT) Date: Thu, 31 May 2012 10:20:12 -0400 From: Cyrus Daboo To: imap5@ietf.org Message-ID: <7EF71BCD5999FCCF89A1E22D@caldav.corp.apple.com> X-Mailer: Mulberry/4.1.0a3 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline; size=2840 Subject: [imap5] Comments on draft-gulbrandsen-imap-move-01 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: Thu, 31 May 2012 14:20:21 -0000 Hi, Some comments on the move extension draft: - =C2=A72: what is the problem with sequence MOVE and EXPUNGE? For what it = is=20 worth Mulberry has always preferred sequence over uids when online (it uses = UID commands when doing disconnected play back). That said, mapping to uids = is no big deal (and should not be a big deal for any other client that=20 might use sequence in normal operation). - =C2=A72: "atomically" - I would prefer not to use the term "atomic" given = that we are allowing partial failures (i.e., some messages might not be=20 moved, whilst others are). So in the first paragraph I suggest changing=20 "atomically" to "using a single command". - =C2=A73: This needs a 3501-like "formal" definition with Arguments:,=20 Responses:, Results: etc. It should use the same text for describing=20 preservation of flags (see note below) and internal date. We need to decide = whether the \Recent flag is set like COPY (probably should be). Also, the=20 [TRYCREATE] behavior from COPY should be re-used. Should probably note that = this command is only valid in selected state (or include a comment to that=20 effect in the formal syntax which 3501 does for the command-select syntax=20 element). - =C2=A73, =C2=B62: "UID EXPUNGE" - need a reference to the UIDPLUS = extension. - =C2=A73, =C2=B64: states that \Deleted must not be set in the target = mailbox. But=20 what if the messages being moved already had \Deleted set prior to the=20 move? Shouldn't we just state that the flag/keywords prior to the move must = be set on the messages in the target mailbox? - =C2=A73: As already mentioned, EXPUNGE responses need to be present. = Might be=20 worth pointing out that there could be a * EXPUNGE for a message not being=20 moved, but which got expunged in another session. Actually, more=20 complicated is the case where a message being moved was expunged in another = session - presumably that message is not moved? Yet it would get reported=20 in a * EXPUNGE, but not be part of the COPYUID set. - =C2=A73: Might want to make it clear that * FETCH FLAGS is NOT sent if = moved=20 messages have \Deleted added as part of the "internal" server=20 implementation of move. - =C2=A73: Example: change "@S:" to "S:". - =C2=A73: COPYUID response in the argument is wrong - it should have three = values: destination mailbox UIDVALIDITY, set of uids from source mailbox,=20 set of uids in destination mailbox. Current example only shows one set of=20 uids. - =C2=A74: whilst no one may implement it, there still ought to be a = reference=20 to the interaction with ANNOTATE. ANNOTATE =C2=A74.6 has detailed text on = the=20 interaction with COPY and something similar is needed for MOVE. - =C2=A76: "command" is not the right syntax element to extend. I would = suggest=20 defining a uidmove element and then use that to extend the 3501 uid = element: uidmove =3D "UID MOVE" SP set SP mailbox uid =3D/ uidmove --=20 Cyrus Daboo From barryleiba.mailing.lists@gmail.com Thu May 31 07:50:55 2012 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 E6CB621F871A for ; Thu, 31 May 2012 07:50:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.023 X-Spam-Level: X-Spam-Status: No, score=-103.023 tagged_above=-999 required=5 tests=[AWL=-0.046, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G5BK83O3rdFi for ; Thu, 31 May 2012 07:50:54 -0700 (PDT) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 2D09121F86B1 for ; Thu, 31 May 2012 07:50:52 -0700 (PDT) Received: by lagv3 with SMTP id v3so841559lag.31 for ; Thu, 31 May 2012 07:50:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=UKMWk+/ZoY5PpKmTptDwt/X6Dt4Nyd7EtRv6eK5W4+I=; b=LKMmQdLxMxPS+49g1VRkGMgKZo3KmQBnf2fzy+Q0/ZH8xXmkEaMSyu2YFk01XLF2cF gEr1R1efSaF97jS4+ssQNlM0v2V0+i8G54qSn1GAqZcbF459YOTA8erAawSH7tEtZl6R RKnAQ+Az+aX7JAgQ2hKnCck/USZ9fH80dHK8Dpi7HEKbvVhC0W76L06EWpxCzY1flZX/ ZEvQvV76SXs3OdIlV+MlWtn4LhMoIJLmuFfWvFeyt6TJTnWEoDjjI9wGpb7tW4Np8dNf C1A815dkopzyc2wY+IeI1Er8BCDr957AZqAaZyMNmh8FmzwPkKekAIUfie1arvU5c6F3 LOsw== MIME-Version: 1.0 Received: by 10.152.103.11 with SMTP id fs11mr2739679lab.23.1338475852100; Thu, 31 May 2012 07:50:52 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.112.48.104 with HTTP; Thu, 31 May 2012 07:50:52 -0700 (PDT) In-Reply-To: <1338473909.19584.15.camel@innu> References: <798B43D6C44C87BB95E00D91@caldav.corp.apple.com> <45BC9626193BD507CCDBB02D@caldav.corp.apple.com> <1338473909.19584.15.camel@innu> Date: Thu, 31 May 2012 10:50:52 -0400 X-Google-Sender-Auth: AXhSld1XLW_zV9Xdq4mr6iIoxz4 Message-ID: From: Barry Leiba To: Timo Sirainen Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: imap5@ietf.org Subject: Re: [imap5] Proposal for "imapmove" working group 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: Thu, 31 May 2012 14:50:55 -0000 >> After some off-list discussion, I think we WILL create a new list, >> . =A0If anyone *objects* to this, please post here >> and say why. =A0Otherwise, the next version of the charter proposal will >> say that. > > I'm not highly against it, but I think we already have too many > imap-related mailing lists. Gets difficult to know sometimes where to > post a question and if all the important people are reading the right > lists. ACK. That was my thinking in wanting to do this here (on imap5). But because this list was chartered for a different purpose, there's (reasonable) concern that there will be distractions in both directions if we temporarily hijack it for this one. I will probably propose to the IESG that we accept this as an exception, and use the list that's already there. That fits better in its purpose, but puts a new WG mailing list off of IETF premises. The IESG has stopped short of saying that should never happen, but has a strong preference against it. So I want everyone to be prepared in case we choose to create a new list. Barry From cyrus@daboo.name Thu May 31 07:59:21 2012 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 56BF321F8587 for ; Thu, 31 May 2012 07:59:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.512 X-Spam-Level: X-Spam-Status: No, score=-102.512 tagged_above=-999 required=5 tests=[AWL=0.087, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rv4wWTAMLySa for ; Thu, 31 May 2012 07:59:20 -0700 (PDT) Received: from daboo.name (daboo.name [173.13.55.49]) by ietfa.amsl.com (Postfix) with ESMTP id B44D721F86E2 for ; Thu, 31 May 2012 07:59:20 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by daboo.name (Postfix) with ESMTP id 0CAF22841D00; Thu, 31 May 2012 10:59:20 -0400 (EDT) X-Virus-Scanned: amavisd-new at daboo.name Received: from daboo.name ([127.0.0.1]) by localhost (daboo.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d1pg1Bp1l3rp; Thu, 31 May 2012 10:59:14 -0400 (EDT) Received: from caldav.corp.apple.com (unknown [17.45.162.46]) by daboo.name (Postfix) with ESMTPSA id D72222841CE4; Thu, 31 May 2012 10:59:12 -0400 (EDT) Date: Thu, 31 May 2012 10:59:08 -0400 From: Cyrus Daboo To: Barry Leiba , Timo Sirainen Message-ID: In-Reply-To: References: <798B43D6C44C87BB95E00D91@caldav.corp.apple.com> <45BC9626193BD507CCDBB02D@caldav.corp.apple.com> <1338473909.19584.15.camel@innu> X-Mailer: Mulberry/4.1.0a3 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline; size=1232 Cc: imap5@ietf.org Subject: Re: [imap5] Proposal for "imapmove" working group 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: Thu, 31 May 2012 14:59:21 -0000 Hi Barry, --On May 31, 2012 10:50:52 AM -0400 Barry Leiba wrote: >> I'm not highly against it, but I think we already have too many >> imap-related mailing lists. Gets difficult to know sometimes where to >> post a question and if all the important people are reading the right >> lists. > > ACK. > That was my thinking in wanting to do this here (on imap5). But > because this list was chartered for a different purpose, there's > (reasonable) concern that there will be distractions in both > directions if we temporarily hijack it for this one. > > I will probably propose to the IESG that we accept this as an > exception, and use the list that's already > there. That fits better in its purpose, but puts a new WG mailing > list off of IETF premises. The IESG has stopped short of saying that > should never happen, but has a strong preference against it. So I > want everyone to be prepared in case we choose to create a new list. Paul at IMC has transferred a number of lists over to IETF control. So would it not make sense to create imapext@ietf.org and transfer over ietf-imapext membership? Then we have one IETF controlled list going forward. -- Cyrus Daboo From tss@iki.fi Thu May 31 08:02:28 2012 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 281E521F876F for ; Thu, 31 May 2012 08:02:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.524 X-Spam-Level: X-Spam-Status: No, score=-110.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sLBg3Cq+qBtH for ; Thu, 31 May 2012 08:02:27 -0700 (PDT) Received: from dovecot.org (dovecot.org [193.210.130.67]) by ietfa.amsl.com (Postfix) with ESMTP id 51A5E21F8770 for ; Thu, 31 May 2012 08:02:27 -0700 (PDT) Received: from [10.217.1.201] (unknown [193.184.212.30]) by dovecot.org (Postfix) with ESMTP id 5B2A71AE87C5; Thu, 31 May 2012 18:02:26 +0300 (EEST) Message-ID: <1338476546.19584.20.camel@innu> From: Timo Sirainen To: Barry Leiba Date: Thu, 31 May 2012 18:02:26 +0300 In-Reply-To: References: <798B43D6C44C87BB95E00D91@caldav.corp.apple.com> <45BC9626193BD507CCDBB02D@caldav.corp.apple.com> <1338473909.19584.15.camel@innu> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.2.3-0ubuntu6 Content-Transfer-Encoding: 7bit Mime-Version: 1.0 Cc: imap5@ietf.org Subject: Re: [imap5] Proposal for "imapmove" working group 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: Thu, 31 May 2012 15:02:28 -0000 On Thu, 2012-05-31 at 10:50 -0400, Barry Leiba wrote: > That was my thinking in wanting to do this here (on imap5). But > because this list was chartered for a different purpose, there's > (reasonable) concern that there will be distractions in both > directions if we temporarily hijack it for this one. > > I will probably propose to the IESG that we accept this as an > exception, and use the list that's already > there. That fits better in its purpose, but puts a new WG mailing > list off of IETF premises. The IESG has stopped short of saying that > should never happen, but has a strong preference against it. So I > want everyone to be prepared in case we choose to create a new list. Would it be possible to create a more generic list for "Any new IMAP-related workgroups"? I'd even prefer if it was somehow aliased to morg list (so that they would really be the same list but with two addresses/names), but I guess that's too much trouble. From barryleiba@gmail.com Thu May 31 08:12:59 2012 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 B3DFC21F87A7 for ; Thu, 31 May 2012 08:12:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.021 X-Spam-Level: X-Spam-Status: No, score=-103.021 tagged_above=-999 required=5 tests=[AWL=-0.044, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y1id6fQxB+kg for ; Thu, 31 May 2012 08:12:58 -0700 (PDT) Received: from mail-gg0-f172.google.com (mail-gg0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3702B21F87A5 for ; Thu, 31 May 2012 08:12:58 -0700 (PDT) Received: by ggnc4 with SMTP id c4so1000454ggn.31 for ; Thu, 31 May 2012 08:12:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=ON0EUA+2tyRYUkPocREtB6sFP9veWpATKCKd5zm3ydQ=; b=SX6tjjYlBkfZMPRUOV69SXTaqRK8u9ENceSi3fPZ26+jrQDso0J5/GHcQqY24nKr/x 7FSF5mgoej8GFhaYqo7JsGcEc/HYBsf46CfwwCmlJe9Kgb5yzkzCw0S2gk1sOPUfp8ku cO+E3Blmk1x+kU2cFq2bGKrR5KgRq54trOOGNfvw//MpINDhwxotBYixnBVM7/FHTyE2 sfia80cBL3VLASE1d10qOkwQ1P4f6d2L/aEfTQ0TQjq6wR8r980JRsNdMANQBeosBBXi E7/o9eTq4w98kRFYcb0r02Fl3Ob3m1QvbTiZCC/xCGumcJcZwzXrxtotOP3JRb4Bh2+I y7SQ== MIME-Version: 1.0 Received: by 10.60.29.41 with SMTP id g9mr2445869oeh.18.1338477177688; Thu, 31 May 2012 08:12:57 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.60.21.35 with HTTP; Thu, 31 May 2012 08:12:57 -0700 (PDT) In-Reply-To: References: <798B43D6C44C87BB95E00D91@caldav.corp.apple.com> <45BC9626193BD507CCDBB02D@caldav.corp.apple.com> <1338473909.19584.15.camel@innu> Date: Thu, 31 May 2012 11:12:57 -0400 X-Google-Sender-Auth: Mp8X3gtwGg7bktmCHZm_cpP1B_M Message-ID: From: Barry Leiba To: Cyrus Daboo Content-Type: text/plain; charset=ISO-8859-1 Cc: Timo Sirainen , imap5@ietf.org Subject: Re: [imap5] Proposal for "imapmove" working group 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: Thu, 31 May 2012 15:12:59 -0000 > Paul at IMC has transferred a number of lists over to IETF control. So would > it not make sense to create imapext@ietf.org and transfer over ietf-imapext > membership? Then we have one IETF controlled list going forward. That's a good suggestion; I'll talk with PH about that. Barry From adrien@qbik.com Thu May 31 13:58:05 2012 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 A39F011E8080 for ; Thu, 31 May 2012 13:58:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.369 X-Spam-Level: X-Spam-Status: No, score=-2.369 tagged_above=-999 required=5 tests=[AWL=0.230, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zJ5Sw-naWznp for ; Thu, 31 May 2012 13:58:05 -0700 (PDT) Received: from smtp.qbik.com (smtp.qbik.com [210.55.214.35]) by ietfa.amsl.com (Postfix) with ESMTP id AA22811E8072 for ; Thu, 31 May 2012 13:58:04 -0700 (PDT) Received: From [192.168.1.10] (unverified [219.89.218.74]) by SMTP Server [210.55.214.35] (WinGate SMTP Receiver v7.2.2 (Build 3416)) with SMTP id <0019055753@smtp.qbik.com>; Fri, 01 Jun 2012 08:58:01 +1200 From: "Adrien W. de Croy" To: "Arnt Gulbrandsen" , "imap5@ietf.org" Date: Thu, 31 May 2012 20:58:11 +0000 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; format=flowed; charset=utf-8 In-Reply-To: <4FC76025.1020508@gulbrandsen.priv.no> Message-Id: Mime-Version: 1.0 User-Agent: eM_Client/4.0.14522.0 Subject: Re: [imap5] Should unsolicited EXPUNGE responses be returned during UID MOVE? X-BeenThere: imap5@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: "Adrien W. de Croy" List-Id: "Discussion on drastically slimming-down IMAP." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 May 2012 20:58:05 -0000 we do need to think whether we're creating a compatibility issue with deployed systems. For instance, if we can't tell whether a client will break on MOVE if we send EXPUNGEs or not, we'd need to basically stop advertising MOVE which completely defeats the purpose. Also. Even though we have to send EXPUNGEs to any other connected client on that mailbox (that didn't do the move), the approach is a bit = wasteful of bandwidth etc. If you issue a command, you want to know when it's done and how it turned out. If the MOVE completes in its entirety without issue (99.99% of the time), then a simple "yeah it worked" response is the most efficient. We can inform of exceptions, e.g. "something broke", or "these messages didn't work". In the end, if there's a failure so what if the client has to resynch indices. But loading the protocol success scenario with major bloat is just that = - bloat. the client said "move these messages". If the server says "I did it", the client can safely act as if the server did it, and remove from local. EXPUNGE responses are completely redundant. Adrien ---- Adrien de Croy - WinGate Proxy Server - http://www.wingate.com WinGate 7 is released! - http://www.wingate.com/getlatest/ ------ Original Message ------ From: "Arnt Gulbrandsen" To: "imap5@ietf.org" Sent: 1/06/2012 12:12:21 a.m. Subject: Re: [imap5] Should unsolicited EXPUNGE responses be returned during UID MOVE? >On 05/30/2012 07:20 PM, Cyrus Daboo wrote: >>Arnt's current spec does not show any * N EXPUNGE responses coming >>back, >>so I am assuming that the client is supposed to implicitly assume the = >>expunges took place, which would cause a problem if they did not take = >>place. But that seems wrong to me - shouldn't UID MOVE cause * N >>EXPUNGE >>to be sent for each message that was actually moved? > >My FUBAR. I'll correct and repost. > >(My code might actually send EXPUNGE a few instants later. I think >that's okay, so long as both server and client change their MSN maps >in sync.) > >Arnt >_______________________________________________ >imap5 mailing list >imap5@ietf.org >https://www.ietf.org/mailman/listinfo/imap5 From tony@att.com Thu May 31 15:07:00 2012 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 BF15B21F865F for ; Thu, 31 May 2012 15:07:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.044 X-Spam-Level: X-Spam-Status: No, score=-106.044 tagged_above=-999 required=5 tests=[AWL=0.555, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uzu7Vbm-nSNv for ; Thu, 31 May 2012 15:07:00 -0700 (PDT) Received: from nbfkord-smmo05.seg.att.com (nbfkord-smmo05.seg.att.com [209.65.160.92]) by ietfa.amsl.com (Postfix) with ESMTP id DC9AF21F8655 for ; Thu, 31 May 2012 15:06:59 -0700 (PDT) Received: from unknown [144.160.20.145] (EHLO mlpd192.enaf.sfdc.sbc.com) by nbfkord-smmo05.seg.att.com(mxl_mta-6.11.0-10) over TLS secured channel with ESMTP id 38be7cf4.0.282654.00-237.793671.nbfkord-smmo05.seg.att.com (envelope-from ); Thu, 31 May 2012 22:06:59 +0000 (UTC) X-MXL-Hash: 4fc7eb837f24c592-7a5cb600a023cd31b5cc9a4c689064bf841bfb60 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id q4VM6xDa022262 for ; Thu, 31 May 2012 18:06:59 -0400 Received: from sflint01.pst.cso.att.com (sflint01.pst.cso.att.com [144.154.234.228]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id q4VM6ulK022252 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 31 May 2012 18:06:58 -0400 Received: from alpd052.aldc.att.com (alpd052.aldc.att.com [130.8.42.31]) by sflint01.pst.cso.att.com (RSA Interceptor) for ; Thu, 31 May 2012 18:06:40 -0400 Received: from aldc.att.com (localhost.localdomain [127.0.0.1]) by alpd052.aldc.att.com (8.14.4/8.14.4) with ESMTP id q4VM6dTp011231 for ; Thu, 31 May 2012 18:06:39 -0400 Received: from dns.maillennium.att.com (mailgw1.maillennium.att.com [135.25.114.99]) by alpd052.aldc.att.com (8.14.4/8.14.4) with ESMTP id q4VM6XAi011067 for ; Thu, 31 May 2012 18:06:33 -0400 Received: from [135.91.110.244] (njcdtl03th1395.itservices.sbc.com[135.91.110.244]) by maillennium.att.com (mailgw1) with ESMTP id <20120531220250gw10060lt4e> (Authid: tony); Thu, 31 May 2012 22:02:53 +0000 X-Originating-IP: [135.91.110.244] Message-ID: <4FC7EB66.6030905@att.com> Date: Thu, 31 May 2012 18:06:30 -0400 From: Tony Hansen User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Timo Sirainen References: <798B43D6C44C87BB95E00D91@caldav.corp.apple.com> <45BC9626193BD507CCDBB02D@caldav.corp.apple.com> <1338473909.19584.15.camel@innu> In-Reply-To: <1338473909.19584.15.camel@innu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-RSA-Inspected: yes X-RSA-Classifications: public X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.20.145] X-AnalysisOut: [v=1.0 c=1 a=p4QNoMogDYAA:10 a=4JAii899aesA:10 a=Po1fWOKDCc] X-AnalysisOut: [8A:10 a=ofMgfj31e3cA:10 a=BLceEmwcHowA:10 a=8nJEP1OIZ-IA:1] X-AnalysisOut: [0 a=ZRNLZ4dFUbCvG8UMqPvVAA==:17 a=48vgC7mUAAAA:8 a=L6IORkp] X-AnalysisOut: [KAAAA:8 a=sycBuuDp-B2vDEyo3wwA:9 a=wPNLvfGTeEIA:10 a=p25YD] X-AnalysisOut: [wzVhg4A:10 a=kkUMZHjH4KkA:10 a=lZB815dzVvQA:10] Cc: imap5@ietf.org Subject: Re: [imap5] Proposal for "imapmove" working group 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: Thu, 31 May 2012 22:07:00 -0000 On 5/31/2012 10:18 AM, Timo Sirainen wrote: > On Thu, 2012-05-31 at 10:10 -0400, Barry Leiba wrote: >> After some off-list discussion, I think we WILL create a new list, >> . If anyone *objects* to this, please post here >> and say why. Otherwise, the next version of the charter proposal will >> say that. > I'm not highly against it, but I think we already have too many > imap-related mailing lists. Gets difficult to know sometimes where to > post a question and if all the important people are reading the right > lists. I was going to attempt some minor humor and suggest using apps-discuss@ietf.org. But seriously, Timo has a very valid point. How about if we look into moving imapext from imc.org to ietf.org, and then use imapext@ietf.org? Tony From tony@att.com Thu May 31 15:11:37 2012 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 BAC0811E8080 for ; Thu, 31 May 2012 15:11:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.229 X-Spam-Level: X-Spam-Status: No, score=-106.229 tagged_above=-999 required=5 tests=[AWL=0.370, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S1EPPfpUJCuB for ; Thu, 31 May 2012 15:11:37 -0700 (PDT) Received: from nbfkord-smmo08.seg.att.com (nbfkord-smmo08.seg.att.com [209.65.160.95]) by ietfa.amsl.com (Postfix) with ESMTP id 0EE3111E807F for ; Thu, 31 May 2012 15:11:36 -0700 (PDT) Received: from unknown [144.160.128.153] (EHLO flpi408.enaf.ffdc.sbc.com) by nbfkord-smmo08.seg.att.com(mxl_mta-6.11.0-10) over TLS secured channel with ESMTP id 79ce7cf4.0.364566.00-403.1022528.nbfkord-smmo08.seg.att.com (envelope-from ); Thu, 31 May 2012 22:11:36 +0000 (UTC) X-MXL-Hash: 4fc7ec980de1494d-8818850788e22cf38e54f36eeeca459e5412767a Received: from enaf.ffdc.sbc.com (localhost.localdomain [127.0.0.1]) by flpi408.enaf.ffdc.sbc.com (8.14.5/8.14.5) with ESMTP id q4VMBZBk019086 for ; Thu, 31 May 2012 15:11:35 -0700 Received: from fflint04.pst.cso.att.com (fflint04.pst.cso.att.com [150.234.39.64]) by flpi408.enaf.ffdc.sbc.com (8.14.5/8.14.5) with ESMTP id q4VMBPbZ018917 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 31 May 2012 15:11:30 -0700 Received: from alpd052.aldc.att.com (alpd052.aldc.att.com [130.8.42.31]) by fflint04.pst.cso.att.com (RSA Interceptor) for ; Thu, 31 May 2012 15:11:16 -0700 Received: from aldc.att.com (localhost.localdomain [127.0.0.1]) by alpd052.aldc.att.com (8.14.4/8.14.4) with ESMTP id q4VMBGA9025174 for ; Thu, 31 May 2012 18:11:16 -0400 Received: from dns.maillennium.att.com (mailgw1.maillennium.att.com [135.25.114.99]) by alpd052.aldc.att.com (8.14.4/8.14.4) with ESMTP id q4VMBClx025085 for ; Thu, 31 May 2012 18:11:12 -0400 Received: from [135.91.110.244] (ds135-91-110-244.dhcps.ugn.att.com[135.91.110.244]) by maillennium.att.com (mailgw1) with ESMTP id <20120531220732gw10060lt6e> (Authid: tony); Thu, 31 May 2012 22:07:32 +0000 X-Originating-IP: [135.91.110.244] Message-ID: <4FC7EC80.6010804@att.com> Date: Thu, 31 May 2012 18:11:12 -0400 From: Tony Hansen User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: imap5@ietf.org References: <798B43D6C44C87BB95E00D91@caldav.corp.apple.com> <45BC9626193BD507CCDBB02D@caldav.corp.apple.com> <1338473909.19584.15.camel@innu> <4FC7EB66.6030905@att.com> In-Reply-To: <4FC7EB66.6030905@att.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-RSA-Inspected: yes X-RSA-Classifications: public X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.128.153] X-AnalysisOut: [v=1.0 c=1 a=p4QNoMogDYAA:10 a=4JAii899aesA:10 a=Po1fWOKDCc] X-AnalysisOut: [8A:10 a=ofMgfj31e3cA:10 a=BLceEmwcHowA:10 a=8nJEP1OIZ-IA:1] X-AnalysisOut: [0 a=xwOvzTHDVLE4u4nGvK72ag==:17 a=48vgC7mUAAAA:8 a=L6IORkp] X-AnalysisOut: [KAAAA:8 a=ZE-I38MU98wQHjbldyAA:9 a=wPNLvfGTeEIA:10 a=p25YD] X-AnalysisOut: [wzVhg4A:10 a=kkUMZHjH4KkA:10 a=lZB815dzVvQA:10] Subject: Re: [imap5] Proposal for "imapmove" working group 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: Thu, 31 May 2012 22:11:37 -0000 On 5/31/2012 6:06 PM, Tony Hansen wrote: > > On 5/31/2012 10:18 AM, Timo Sirainen wrote: >> On Thu, 2012-05-31 at 10:10 -0400, Barry Leiba wrote: >>> After some off-list discussion, I think we WILL create a new list, >>> . If anyone *objects* to this, please post here >>> and say why. Otherwise, the next version of the charter proposal will >>> say that. >> I'm not highly against it, but I think we already have too many >> imap-related mailing lists. Gets difficult to know sometimes where to >> post a question and if all the important people are reading the right >> lists. > > I was going to attempt some minor humor and suggest using > apps-discuss@ietf.org. > > But seriously, Timo has a very valid point. > > How about if we look into moving imapext from imc.org to ietf.org, and > then use imapext@ietf.org? > > Tony Sorry about the duplicate suggestion -- that's what I get for not hitting Send right away, and then clearing off my desktop before quitting time without looking to see how the discussion has progressed. Tony From arnt@gulbrandsen.priv.no Thu May 31 23:03:33 2012 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 2F25821F8599 for ; Thu, 31 May 2012 23:03:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.246 X-Spam-Level: X-Spam-Status: No, score=-2.246 tagged_above=-999 required=5 tests=[AWL=0.353, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P5+1EtIKVYrC for ; Thu, 31 May 2012 23:03:32 -0700 (PDT) Received: from strange.aox.org (strange.aox.org [IPv6:2001:4d88:100c::1]) by ietfa.amsl.com (Postfix) with ESMTP id 963C321F851A for ; Thu, 31 May 2012 23:03:32 -0700 (PDT) Received: from fri.gulbrandsen.priv.no (unknown [127.0.0.1]) by strange.aox.org (Postfix) with ESMTP id 62086F8D90F; Fri, 1 Jun 2012 06:03:31 +0000 (UTC) Received: from arnt@gulbrandsen.priv.no by fri.gulbrandsen.priv.no (Archiveopteryx 3.1.4) with esmtpsa id 1338530610-10044-10043/11/8; Fri, 1 Jun 2012 06:03:30 +0000 Message-Id: <4FC85B2E.3030808@gulbrandsen.priv.no> Date: Fri, 1 Jun 2012 08:03:26 +0200 From: Arnt Gulbrandsen User-Agent: Mozilla/5.0 (X11; Linux i686; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 Mime-Version: 1.0 To: "Adrien W. de Croy" References: <4FC76025.1020508@gulbrandsen.priv.no> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Cc: imap5@ietf.org Subject: Re: [imap5] Should unsolicited EXPUNGE responses be returned during UID MOVE? 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: Fri, 01 Jun 2012 06:03:33 -0000 Listen closely. The missing EXPUNGEs are a document bug, not representative of any servers I know. Arnt