From iesg-secretary@ietf.org Wed Nov 7 15:05:52 2012 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3112221F8AAD; Wed, 7 Nov 2012 15:05:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.56 X-Spam-Level: X-Spam-Status: No, score=-102.56 tagged_above=-999 required=5 tests=[AWL=0.039, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ug3LoKNjYi1d; Wed, 7 Nov 2012 15:05:47 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C628A21F8A72; Wed, 7 Nov 2012 15:05:47 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.36 Message-ID: <20121107230547.27835.91507.idtracker@ietfa.amsl.com> Date: Wed, 07 Nov 2012 15:05:47 -0800 Cc: imapext@ietf.org Subject: [imapext] Last Call: (The IMAP Move Extension) to Proposed Standard X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ietf@ietf.org List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Nov 2012 23:05:52 -0000 The IESG has received a request from the IMAP MOVE extension WG (imapmove) to consider the following document: - 'The IMAP Move Extension' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2012-11-21. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document defines an IMAP extension consisting of two new commands, MOVE and UID MOVE, that are used to move messages from one mailbox to another. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-imapmove-command/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-imapmove-command/ballot/ No IPR declarations have been submitted directly on this I-D. From jkt@flaska.net Thu Nov 8 05:00:02 2012 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64BC821F84B9 for ; Thu, 8 Nov 2012 05:00:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.28 X-Spam-Level: X-Spam-Status: No, score=-1.28 tagged_above=-999 required=5 tests=[AWL=1.020, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QxFWCTrVP+2P for ; Thu, 8 Nov 2012 05:00:02 -0800 (PST) Received: from latimerie.flaska.net (latimerie.flaska.net [IPv6:2a02:2b88:2:1::4a7:333]) by ietfa.amsl.com (Postfix) with ESMTP id D8B2121F8793 for ; Thu, 8 Nov 2012 05:00:01 -0800 (PST) Received: by latimerie.flaska.net (Postfix, from userid 1000) id 1C30F61BFA; Thu, 8 Nov 2012 14:00:02 +0100 (CET) From: =?iso-8859-1?Q?Jan_Kundr=E1t?= To: Date: Thu, 08 Nov 2012 13:59:05 +0100 User-Agent: trojita/v0.3-1424-g89e2705; Qt/4.8.3; X11; Linux; MIME-Version: 1.0 Message-ID: <5916d94e-5b18-48fd-96e1-af1347b8d376@flaska.net> In-Reply-To: <20121107230547.27835.91507.idtracker@ietfa.amsl.com> References: <20121107230547.27835.91507.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Subject: [imapext] =?iso-8859-1?q?_Re=3A_Last_Call=3A_=3Cdraft-ietf-imapmo?= =?iso-8859-1?q?ve-command-02=2Etxt=3E_=28The_IMAP_Move_Extension?= =?iso-8859-1?q?=29_to_Proposed_Standard?= X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Nov 2012 13:00:02 -0000 Hi, section 4.1 still says that "This may be user-visible, but should n= ot be MUA-visible." which is a sentence whose meaning I cannot decipher= . People on this ML have also said that it should probably be removed.=0A= =0ASo, what has to be done to get rid of it? (I suspect that is is not = a "substantive comment" that the IETF seeks, which is why I'm sending t= his just to the imapext).=0A=0AWith kind regards,=0AJan From ned.freed@mrochek.com Thu Nov 8 07:43:41 2012 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9D1A21F855E for ; Thu, 8 Nov 2012 07:43:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.419 X-Spam-Level: X-Spam-Status: No, score=-2.419 tagged_above=-999 required=5 tests=[AWL=-0.120, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j03jHYNn2XzL for ; Thu, 8 Nov 2012 07:43:41 -0800 (PST) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id C91B521F84E9 for ; Thu, 8 Nov 2012 07:43:40 -0800 (PST) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OMDF3UE97K001EIY@mauve.mrochek.com> for imapext@ietf.org; Thu, 8 Nov 2012 07:38:20 -0800 (PST) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OMD1D50RGW00008S@mauve.mrochek.com>; Thu, 8 Nov 2012 07:38:18 -0800 (PST) Message-id: <01OMDF3SUNT600008S@mauve.mrochek.com> Date: Thu, 08 Nov 2012 07:37:23 -0800 (PST) From: Ned Freed In-reply-to: "Your message dated Thu, 08 Nov 2012 13:59:05 +0100" <5916d94e-5b18-48fd-96e1-af1347b8d376@flaska.net> MIME-version: 1.0 Content-type: TEXT/PLAIN; Format=flowed References: <20121107230547.27835.91507.idtracker@ietfa.amsl.com> <5916d94e-5b18-48fd-96e1-af1347b8d376@flaska.net> To: =?iso-8859-1?Q?Jan_Kundr=E1t?= Cc: imapext@ietf.org Subject: Re: [imapext] =?iso-8859-1?q?Last_Call=3A_=3Cdraft-ietf-imapmove-comm?= =?iso-8859-1?q?and-02=2Etxt=3E_=28The_IMAP_Move_Extension=29_to_Proposed_?= =?iso-8859-1?q?Standard?= X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Nov 2012 15:43:41 -0000 > Hi, section 4.1 still says that "This may be user-visible, but should not be > MUA-visible." which is a sentence whose meaning I cannot decipher. People on > this ML have also said that it should probably be removed. It will be removed the next time an updated draft is posted. Ned From ck@cketti.de Fri Nov 9 09:30:14 2012 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE7B021F8778 for ; Fri, 9 Nov 2012 09:30:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qiOKRSJt8ymz for ; Fri, 9 Nov 2012 09:30:14 -0800 (PST) Received: from mo6-p00-ob.rzone.de (mo6-p00-ob.rzone.de [IPv6:2a01:238:20a:202:5300::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F2D421F847F for ; Fri, 9 Nov 2012 09:30:10 -0800 (PST) X-RZG-AUTH: :L2ckdkutb+sebmQwUUWXIIEVZnY3Sox1TzADcdlun/VDrZwf X-RZG-CLASS-ID: mo00 Received: from [192.168.1.107] (HSI-KBW-078-043-007-202.hsi4.kabel-badenwuerttemberg.de [78.43.7.202]) by smtp.strato.de (josoe mo47) (RZmta 31.2 DYNA|AUTH) with ESMTPA id K06aa2oA9GO3KJ for ; Fri, 9 Nov 2012 18:30:04 +0100 (CET) Message-ID: <509D3D99.4010305@cketti.de> Date: Fri, 09 Nov 2012 18:30:01 +0100 From: Christian Ketterer User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: imapext@ietf.org References: <20121107230547.27835.91507.idtracker@ietfa.amsl.com> In-Reply-To: <20121107230547.27835.91507.idtracker@ietfa.amsl.com> X-Enigmail-Version: 1.4.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [imapext] Last Call: (The IMAP Move Extension) to Proposed Standard X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Nov 2012 17:30:15 -0000 Hi, I have a couple of remarks on the draft. 1. In section 3.1 the argument "mailbox name" isn't indented correctly. 2. In section 6 mailboxes are referred to as "folders". 3. English is not my first language, but the end of this sentence in section 6 sounds wrong: "Scanning with updated rules may also be required when messages are moved even with the underlying policy has not changed." 4. The document doesn't explicitly state that a server announces support for this extension by returning the capability "MOVE" in the response to the CAPABILITY command. 5. The document doesn't explicitly state what responses look like in case of a partial failure. I believe adding this would be helpful to readers not intimately familiar with IMAP. Best, Chris From ned.freed@mrochek.com Fri Nov 9 10:09:37 2012 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DBD221F8771 for ; Fri, 9 Nov 2012 10:09:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.549 X-Spam-Level: X-Spam-Status: No, score=-2.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PftZYEIVoYgI for ; Fri, 9 Nov 2012 10:09:32 -0800 (PST) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id 82EC921F85CD for ; Fri, 9 Nov 2012 10:09:32 -0800 (PST) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OMEYICKMPS001H7H@mauve.mrochek.com> for imapext@ietf.org; Fri, 9 Nov 2012 10:04:28 -0800 (PST) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OMD1D50RGW00008S@mauve.mrochek.com>; Fri, 9 Nov 2012 10:04:25 -0800 (PST) Message-id: <01OMEYIBDO7A00008S@mauve.mrochek.com> Date: Fri, 09 Nov 2012 09:53:32 -0800 (PST) From: Ned Freed In-reply-to: "Your message dated Fri, 09 Nov 2012 18:30:01 +0100" <509D3D99.4010305@cketti.de> MIME-version: 1.0 Content-type: TEXT/PLAIN References: <20121107230547.27835.91507.idtracker@ietfa.amsl.com> <509D3D99.4010305@cketti.de> To: Christian Ketterer Cc: imapext@ietf.org Subject: Re: [imapext] Last Call: (The IMAP Move Extension) to Proposed Standard X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Nov 2012 18:09:37 -0000 > Hi, > I have a couple of remarks on the draft. > 1. In section 3.1 the argument "mailbox name" isn't indented correctly. Not sure how that happened. Fixed. > 2. In section 6 mailboxes are referred to as "folders". An error on my part. Fixed. > 3. English is not my first language, but the end of this sentence in > section 6 sounds wrong: "Scanning with updated rules may also be > required when messages are moved even with the underlying policy has not > changed." "with" should be "when". Fixed. > 4. The document doesn't explicitly state that a server announces support > for this extension by returning the capability "MOVE" in the response to > the CAPABILITY command. Yes, this seems to be essentially boilerplate for IMAP extension documents. I'll add the appropriate text. > 5. The document doesn't explicitly state what responses look like in > case of a partial failure. I believe adding this would be helpful to > readers not intimately familiar with IMAP. I'm not really sure that's true. The problem I've seen fairly often with examples of how errors get reported is that implementors then assume that's the only sort of error that can happen. This is compounded when you're talking about partial failures. Anyway, if you want a change in this area, someone needs to suggest text. Thanks for the feedback. Ned From slusarz@horde.org Tue Nov 13 23:51:18 2012 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 104DA21F8546 for ; Tue, 13 Nov 2012 23:51:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.422 X-Spam-Level: * X-Spam-Status: No, score=1.422 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wT27Z4jx2CpT for ; Tue, 13 Nov 2012 23:51:17 -0800 (PST) Received: from qmta05.emeryville.ca.mail.comcast.net (qmta05.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:43:76:96:30:48]) by ietfa.amsl.com (Postfix) with ESMTP id D39CE21F8563 for ; Tue, 13 Nov 2012 23:51:16 -0800 (PST) Received: from omta14.emeryville.ca.mail.comcast.net ([76.96.30.60]) by qmta05.emeryville.ca.mail.comcast.net with comcast id PKpf1k0031HpZEsA5KrGe4; Wed, 14 Nov 2012 07:51:16 +0000 Received: from bigworm.curecanti.org ([71.229.167.0]) by omta14.emeryville.ca.mail.comcast.net with comcast id PKrE1k00m00qwSn8aKrF2Q; Wed, 14 Nov 2012 07:51:15 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by bigworm.curecanti.org (Postfix) with ESMTP id 7472013036 for ; Wed, 14 Nov 2012 00:50:44 -0700 (MST) Received: from schrute.curecanti.org (schrute.curecanti.org [172.18.5.4]) by bigworm.curecanti.org (Horde Framework) with HTTP; Wed, 14 Nov 2012 00:50:44 -0700 Date: Wed, 14 Nov 2012 00:50:44 -0700 Message-ID: <20121114005044.Horde.7cjcX-E8Scrushgd26OdcA8@bigworm.curecanti.org> From: Michael M Slusarz To: imapext@ietf.org User-Agent: Internet Messaging Program (IMP) H5 (6.1.0-git) Accept-Language: en X-Originating-IP: 172.18.5.4 X-Remote-Browser: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20100101 Firefox/16.0 Content-Type: text/plain; charset=UTF-8; format=flowed; DelSp=Yes MIME-Version: 1.0 Content-Disposition: inline Subject: Re: [imapext] Last Call: (The IMAP Move Extension) to Proposed Standard, X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Nov 2012 08:08:33 -0000 Scanning the draft text, this was the one section that stuck out to me: 4.4. RFC 5162, QRESYNC The QRESYNC extension [RFC5162] directs the server to send VANISHED rather than EXPUNGE in response to the UID EXPUNGE command. The same requirement applies to the UID MOVE command. My opinion: this is a slightly inaccurate representation of QRESYNC. QRESYNC only states that servers "SHOULD start sending VANISHED responses . . . instead of EXPUNGE responses." (RFC 5162 [1]). See also RFC 5162 [3.5] (as a result of UID EXPUNGE command, "those messages that are removed are reported using a VANISHED response or EXPUNGE responses."). The use of "directs" and "requirement" in draft section 4.4 implies that VANISHED messages MUST be sent. At least that's the way I read this section the first several times scanning the document. As a disconnected IMAP client author, this would be fantastic if true but, alas, that is not the case. Complaints without suggestions are not very useful, so here's a possible rephrasing: The QRESYNC extension [RFC5162] advises that the server send VANISHED rather than EXPUNGE in response to the UID EXPUNGE command. A QRESYNC enabled client MUST be prepared to handle both VANISHED and EXPUNGE responses to a UID MOVE command. thanks, michael ___________________________________ Michael Slusarz [slusarz@horde.org] From barryleiba.mailing.lists@gmail.com Wed Nov 14 06:15:21 2012 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DEAD21F8500 for ; Wed, 14 Nov 2012 06:15:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.85 X-Spam-Level: X-Spam-Status: No, score=-102.85 tagged_above=-999 required=5 tests=[AWL=0.126, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rvuTNTSXoR+c for ; Wed, 14 Nov 2012 06:15:20 -0800 (PST) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 5B54D21F84F8 for ; Wed, 14 Nov 2012 06:15:20 -0800 (PST) Received: by mail-lb0-f172.google.com with SMTP id y2so482064lbk.31 for ; Wed, 14 Nov 2012 06:15:18 -0800 (PST) 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=au7ZRLiyREcq4EfZCO6Vj3bJHzTdTxFxnMcCZRWpGNE=; b=h7Wv5NKVl9nSwH7QeUHPsNBQsyY70M9yZN/MAClGk9fP3zisMMrgfqjOdCq2ebLNpe Bu6kjfTPRsPyFQ8DZovX0oAMhAQyjyE8fZqaKQZrirNkcuirvkvhm9LYKvFX0Uqdi5qL /B5hybz/GyM1oy3rb4fCRhDlHE+gcyZU+uiZESGvp7B6hv+0EVhZlQqSxUc2ZSYrUVAI 9/soAu2Rjxo4MlaEt1VQhuy1uo4M6rpYHoya+9Ce0QxGdNAkJ3htSxSdNQdEIpJHWuaf QNMuIK7Zzp/anakvE5sJQFO0sVFrblmd1l60wWbkFqPXYCFqhjm5RicSp2NTQQeOXgUo 6tVg== MIME-Version: 1.0 Received: by 10.112.10.34 with SMTP id f2mr11137967lbb.47.1352902518545; Wed, 14 Nov 2012 06:15:18 -0800 (PST) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.112.12.166 with HTTP; Wed, 14 Nov 2012 06:15:18 -0800 (PST) In-Reply-To: <20121114005044.Horde.7cjcX-E8Scrushgd26OdcA8@bigworm.curecanti.org> References: <20121114005044.Horde.7cjcX-E8Scrushgd26OdcA8@bigworm.curecanti.org> Date: Wed, 14 Nov 2012 09:15:18 -0500 X-Google-Sender-Auth: WAP6gb_8bAITuv4paen4uKvpMqY Message-ID: From: Barry Leiba To: Michael M Slusarz Content-Type: multipart/alternative; boundary=485b390f792a089eb404ce752adf Cc: "imapext@ietf.org" Subject: Re: [imapext] Last Call: (The IMAP Move Extension) to Proposed Standard, X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Nov 2012 14:15:21 -0000 --485b390f792a089eb404ce752adf Content-Type: text/plain; charset=ISO-8859-1 Good catch, Michael. Let me suggest a slight variant of your suggestion: OLD > The QRESYNC extension [RFC5162] directs the server to send VANISHED > rather than EXPUNGE in response to the UID EXPUNGE command. The same > requirement applies to the UID MOVE command. NEW > The QRESYNC extension [RFC5162] advises that the server send VANISHED > rather than EXPUNGE in response to the UID EXPUNGE command. The same > advice applies to MOVE, and a QRESYNC-enabled client > needs to handle both VANISHED and EXPUNGE responses to a UID MOVE > command. Barry --485b390f792a089eb404ce752adf Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Good catch, Michael. =A0Let me suggest a slight variant of your suggestion:=

OLD
=A0 =A0The QRESYNC extension [RFC5162] directs the server to send VANISHED<= br> =A0 =A0rather than EXPUNGE in response to the UID EXPUNGE command. =A0The s= ame
=A0 =A0requirement applies to the UID MOVE command.

NEW
=A0 =A0The QRESYNC extension [RFC5162] advises that the server send VANISHE= D
=A0 =A0rather than EXPUNGE in response to the UID EXPUNGE command. =A0The s= ame advice applies to MOVE, and a QRESYNC-enabled client
=A0 =A0needs to= handle both VANISHED and EXPUNGE responses to a UID MOVE command.

Barry=A0
--485b390f792a089eb404ce752adf-- From ned.freed@mrochek.com Wed Nov 14 08:41:50 2012 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4AEF21F85C9 for ; Wed, 14 Nov 2012 08:41:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.532 X-Spam-Level: X-Spam-Status: No, score=-2.532 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RPuihxjeRARU for ; Wed, 14 Nov 2012 08:41:50 -0800 (PST) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id 340BB21F85C3 for ; Wed, 14 Nov 2012 08:41:48 -0800 (PST) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OMLUW29OVK001PSJ@mauve.mrochek.com> for imapext@ietf.org; Wed, 14 Nov 2012 08:36:32 -0800 (PST) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OMGB2WUMLC00008S@mauve.mrochek.com>; Wed, 14 Nov 2012 08:36:30 -0800 (PST) Message-id: <01OMLUW13XPW00008S@mauve.mrochek.com> Date: Wed, 14 Nov 2012 08:26:30 -0800 (PST) From: Ned Freed In-reply-to: "Your message dated Wed, 14 Nov 2012 09:15:18 -0500" MIME-version: 1.0 Content-type: TEXT/PLAIN References: <20121114005044.Horde.7cjcX-E8Scrushgd26OdcA8@bigworm.curecanti.org> To: Barry Leiba Cc: Michael M Slusarz , "imapext@ietf.org" Subject: Re: [imapext] Last Call: (The IMAP Move Extension) to Proposed Standard, X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Nov 2012 16:41:50 -0000 > Good catch, Michael. Let me suggest a slight variant of your suggestion: > OLD > > The QRESYNC extension [RFC5162] directs the server to send VANISHED > > rather than EXPUNGE in response to the UID EXPUNGE command. The same > > requirement applies to the UID MOVE command. > NEW > > The QRESYNC extension [RFC5162] advises that the server send VANISHED > > rather than EXPUNGE in response to the UID EXPUNGE command. The same > > advice applies to MOVE, and a QRESYNC-enabled client > > needs to handle both VANISHED and EXPUNGE responses to a UID MOVE > > command. Except that's not correct either. RFC 5162 uses a SHOULD; that's requirements language, not merely advice. In fact the current text is not that far off. Instead of trying to come up with a way of rephrasing what RFC 5162 says, how about we restate what it actually says? The QRESYNC extension [RFC5162] states that the server SHOULD send VANISHED rather than the EXPUNGE in response to the UID EXPUNGE command. The same requirement applies to MOVE, and a QRESYNC-enabled client needs to handle both VANISHED and EXPUNGE responses to a UID MOVE command. Ned From barryleiba.mailing.lists@gmail.com Wed Nov 14 09:04:52 2012 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF15121F86F5 for ; Wed, 14 Nov 2012 09:04:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.869 X-Spam-Level: X-Spam-Status: No, score=-102.869 tagged_above=-999 required=5 tests=[AWL=0.108, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nA7h0Tf-Cx+r for ; Wed, 14 Nov 2012 09:04:52 -0800 (PST) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 0D8E521F86D0 for ; Wed, 14 Nov 2012 09:04:51 -0800 (PST) Received: by mail-lb0-f172.google.com with SMTP id y2so643807lbk.31 for ; Wed, 14 Nov 2012 09:04:50 -0800 (PST) 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=qDqF8VGDp276Xy6fFP5Jj6k8grnmOggmk5YQ4H4cLpw=; b=Hq9xVuvtVGeJNEuJYShui/gYxzW2pOpx1F8be27rLw+6T2bJimEpt4D1yfdYq7heK3 BVVFwFp+i1fRgD9fuleNGrTEU5PIG4iwYf/BnkWOntxEUn1jcinb47i3PGuWLt6Kw0s1 3Aka0SBoGRjQavv4tQp1JZ2DLM2l8vgjQJKPBZYLgIQ93TMMU7h4xra0PBnyQnSeire3 5xFvGfJ9JCNpL9wdU0hvRJ9HMHlNb5oMHhCphuDHctfg1kRXCrU5gU+kdPxyA5GuawvF CZWqGhk1vxNEe3iXQIa51NaWafiTIqwpLt8HhwbXGzdDmJMmrwIc/VCO1j1EKKckx7Sh HQxA== MIME-Version: 1.0 Received: by 10.112.85.196 with SMTP id j4mr5339657lbz.132.1352912690770; Wed, 14 Nov 2012 09:04:50 -0800 (PST) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.112.12.166 with HTTP; Wed, 14 Nov 2012 09:04:50 -0800 (PST) In-Reply-To: <01OMLUW13XPW00008S@mauve.mrochek.com> References: <20121114005044.Horde.7cjcX-E8Scrushgd26OdcA8@bigworm.curecanti.org> <01OMLUW13XPW00008S@mauve.mrochek.com> Date: Wed, 14 Nov 2012 12:04:50 -0500 X-Google-Sender-Auth: egvCJ2euBIuhZCdD9APE9CkkJt0 Message-ID: From: Barry Leiba To: Ned Freed Content-Type: text/plain; charset=ISO-8859-1 Cc: Michael M Slusarz , "imapext@ietf.org" Subject: Re: [imapext] Last Call: (The IMAP Move Extension) to Proposed Standard, X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Nov 2012 17:04:52 -0000 > Instead of trying to come up with a way of rephrasing what RFC 5162 says, > how about we restate what it actually says? > > The QRESYNC extension [RFC5162] states that the server SHOULD send VANISHED > rather than the EXPUNGE in response to the UID EXPUNGE command. > The same requirement applies to MOVE, and a QRESYNC-enabled client > needs to handle both VANISHED and EXPUNGE responses to a UID MOVE > command. Oui. Parfait. Barry From slusarz@horde.org Wed Nov 14 09:12:59 2012 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF7FB21F8773 for ; Wed, 14 Nov 2012 09:12:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.38 X-Spam-Level: X-Spam-Status: No, score=-0.38 tagged_above=-999 required=5 tests=[AWL=0.057, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YvomugmUEVj2 for ; Wed, 14 Nov 2012 09:12:58 -0800 (PST) Received: from qmta03.emeryville.ca.mail.comcast.net (qmta03.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:43:76:96:30:32]) by ietfa.amsl.com (Postfix) with ESMTP id DBB2321F876B for ; Wed, 14 Nov 2012 09:12:55 -0800 (PST) Received: from omta17.emeryville.ca.mail.comcast.net ([76.96.30.73]) by qmta03.emeryville.ca.mail.comcast.net with comcast id PUEJ1k0091afHeLA3VCvnz; Wed, 14 Nov 2012 17:12:55 +0000 Received: from bigworm.curecanti.org ([71.229.167.0]) by omta17.emeryville.ca.mail.comcast.net with comcast id PVCt1k00v00qwSn8dVCukw; Wed, 14 Nov 2012 17:12:54 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by bigworm.curecanti.org (Postfix) with ESMTP id 4DC5813036 for ; Wed, 14 Nov 2012 10:12:23 -0700 (MST) Received: from schrute.curecanti.org (schrute.curecanti.org [172.18.5.4]) by bigworm.curecanti.org (Horde Framework) with HTTP; Wed, 14 Nov 2012 10:12:23 -0700 Date: Wed, 14 Nov 2012 10:12:23 -0700 Message-ID: <20121114101223.Horde.bkBR67pZ5okx6Penvp4ziQ9@bigworm.curecanti.org> From: Michael M Slusarz To: imapext@ietf.org References: <20121114005044.Horde.7cjcX-E8Scrushgd26OdcA8@bigworm.curecanti.org> <01OMLUW13XPW00008S@mauve.mrochek.com> In-Reply-To: User-Agent: Internet Messaging Program (IMP) H5 (6.0.2-git) Accept-Language: en X-Originating-IP: 172.18.5.4 X-Remote-Browser: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20100101 Firefox/16.0 Content-Type: text/plain; charset=UTF-8; format=flowed; DelSp=Yes MIME-Version: 1.0 Content-Disposition: inline Subject: Re: [imapext] Last Call: (The IMAP Move Extension) to Proposed Standard, X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Nov 2012 17:12:59 -0000 Quoting Barry Leiba : >> Instead of trying to come up with a way of rephrasing what RFC 5162 says, >> how about we restate what it actually says? >> >> The QRESYNC extension [RFC5162] states that the server SHOULD >> send VANISHED >> rather than the EXPUNGE in response to the UID EXPUNGE command. >> The same requirement applies to MOVE, and a QRESYNC-enabled client >> needs to handle both VANISHED and EXPUNGE responses to a UID MOVE >> command. > > Oui. Parfait. A clarity suggestion: we have the MOVE extension, the MOVE command, and the MOVE addition to the the UID command. It would be useful to clarify that it is the MOVE extension being referred to in this context: The QRESYNC extension [RFC5162] states that the server SHOULD send VANISHED rather than the EXPUNGE in response to the UID EXPUNGE command. The same requirement applies to [the MOVE | this] extension, and a QRESYNC-enabled client needs to handle both VANISHED and EXPUNGE responses to a UID MOVE command. michael ___________________________________ Michael Slusarz [slusarz@horde.org] From ned.freed@mrochek.com Wed Nov 14 09:39:02 2012 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D29C21F86E7 for ; Wed, 14 Nov 2012 09:39:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.539 X-Spam-Level: X-Spam-Status: No, score=-2.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 02da6QPdadNS for ; Wed, 14 Nov 2012 09:39:02 -0800 (PST) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id 8512321F86D6 for ; Wed, 14 Nov 2012 09:39:00 -0800 (PST) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OMLWW61FZ4001QIR@mauve.mrochek.com> for imapext@ietf.org; Wed, 14 Nov 2012 09:33:53 -0800 (PST) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OMGB2WUMLC00008S@mauve.mrochek.com>; Wed, 14 Nov 2012 09:33:50 -0800 (PST) Message-id: <01OMLWW46K2I00008S@mauve.mrochek.com> Date: Wed, 14 Nov 2012 09:33:30 -0800 (PST) From: Ned Freed In-reply-to: "Your message dated Wed, 14 Nov 2012 12:04:50 -0500" MIME-version: 1.0 Content-type: TEXT/PLAIN References: <20121114005044.Horde.7cjcX-E8Scrushgd26OdcA8@bigworm.curecanti.org> <01OMLUW13XPW00008S@mauve.mrochek.com> To: Barry Leiba Cc: Michael M Slusarz , Ned Freed , "imapext@ietf.org" Subject: Re: [imapext] Last Call: (The IMAP Move Extension) to Proposed Standard, X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Nov 2012 17:39:02 -0000 > > Instead of trying to come up with a way of rephrasing what RFC 5162 says, > > how about we restate what it actually says? > > > > The QRESYNC extension [RFC5162] states that the server SHOULD send VANISHED > > rather than the EXPUNGE in response to the UID EXPUNGE command. > > The same requirement applies to MOVE, and a QRESYNC-enabled client > > needs to handle both VANISHED and EXPUNGE responses to a UID MOVE > > command. > Oui. Parfait. Great. I've updated the doc with this text. Ned From ned.freed@mrochek.com Wed Nov 14 09:39:06 2012 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BB3A21F8769 for ; Wed, 14 Nov 2012 09:39:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.544 X-Spam-Level: X-Spam-Status: No, score=-2.544 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yb9BCUD6wJ27 for ; Wed, 14 Nov 2012 09:39:06 -0800 (PST) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id 110D621F86FF for ; Wed, 14 Nov 2012 09:39:04 -0800 (PST) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OMLWZEFH00001QIR@mauve.mrochek.com> for imapext@ietf.org; Wed, 14 Nov 2012 09:36:29 -0800 (PST) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OMGB2WUMLC00008S@mauve.mrochek.com>; Wed, 14 Nov 2012 09:36:27 -0800 (PST) Message-id: <01OMLWZD4HU200008S@mauve.mrochek.com> Date: Wed, 14 Nov 2012 09:35:27 -0800 (PST) From: Ned Freed In-reply-to: "Your message dated Wed, 14 Nov 2012 10:12:23 -0700" <20121114101223.Horde.bkBR67pZ5okx6Penvp4ziQ9@bigworm.curecanti.org> MIME-version: 1.0 Content-type: TEXT/PLAIN; Format=flowed; DelSp=Yes References: <20121114005044.Horde.7cjcX-E8Scrushgd26OdcA8@bigworm.curecanti.org> <01OMLUW13XPW00008S@mauve.mrochek.com> <20121114101223.Horde.bkBR67pZ5okx6Penvp4ziQ9@bigworm.curecanti.org> To: Michael M Slusarz Cc: imapext@ietf.org Subject: Re: [imapext] Last Call: (The IMAP Move Extension) to Proposed Standard, X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Nov 2012 17:39:06 -0000 > Quoting Barry Leiba : > >> Instead of trying to come up with a way of rephrasing what RFC 5162 says, > >> how about we restate what it actually says? > >> > >> The QRESYNC extension [RFC5162] states that the server SHOULD > >> send VANISHED > >> rather than the EXPUNGE in response to the UID EXPUNGE command. > >> The same requirement applies to MOVE, and a QRESYNC-enabled client > >> needs to handle both VANISHED and EXPUNGE responses to a UID MOVE > >> command. > > > > Oui. Parfait. > A clarity suggestion: we have the MOVE extension, the MOVE command, > and the MOVE addition to the the UID command. It would be useful to > clarify that it is the MOVE extension being referred to in this context: > The QRESYNC extension [RFC5162] states that the server SHOULD > send VANISHED > rather than the EXPUNGE in response to the UID EXPUNGE command. > The same requirement applies to [the MOVE | this] extension, > and a QRESYNC-enabled client needs to handle both VANISHED and > EXPUNGE responses > to a UID MOVE command. We use "MOVE" as shorthand for the MOVE extension all over the place; I see no reason to change this one occurence. Ned From barryleiba@computer.org Mon Nov 19 16:44:57 2012 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BC5421F87D9; Mon, 19 Nov 2012 16:44:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gewFnNwwNpik; Mon, 19 Nov 2012 16:44:55 -0800 (PST) Received: from server1.netnutz.com (server1.netnutz.com [72.233.90.3]) by ietfa.amsl.com (Postfix) with ESMTP id 72B2421F87D7; Mon, 19 Nov 2012 16:44:55 -0800 (PST) Received: from ool-4a599ef4.dyn.optonline.net ([74.89.158.244]:59706 helo=[192.168.0.2]) by server1.netnutz.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80) (envelope-from ) id 1TabxO-0001WR-Kk; Mon, 19 Nov 2012 19:44:55 -0500 Date: Mon, 19 Nov 2012 19:44:51 -0500 From: Barry Leiba To: imap5@ietf.org, imapext@ietf.org, imap-protocol@u.washington.edu, imap-use@u.washington.edu Message-ID: X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server1.netnutz.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - computer.org X-Get-Message-Sender-Via: server1.netnutz.com: authenticated_id: barryleiba@internetmessagingtechnology.org Subject: [imapext] News about Mark Crispin X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: imap5@ietf.org List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Nov 2012 00:44:57 -0000 Everyone here knows Mark Crispin -- or at least knows who he is: Mark is the author of the original IMAP specification, and has taken it through its different versions to the present IMAP4rev1. He's written reference implementations of both server and client, and has been a vocal participant on all the mailing lists I'm posting this to. I'm sad to have to report that Mark is now terminally ill, and is in hospice care. For now, at least, I'm told that Mark is at least somewhat aware. If anyone has brief well-wishing messages they'd like to send him, please post them to the mailing list, and I'll forward them to Mark's long-term companion, Annie. I will also post updates to that list as I get them. [The Reply-To for this message is set to , so that replies will go there. You will have to subscribe to that mailing list in order to post to it. You can do that here: http://www.ietf.org/mailman/listinfo/imap5 ] Barry Leiba From internet-drafts@ietf.org Wed Nov 21 16:47:03 2012 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9E9121E8044; Wed, 21 Nov 2012 16:47:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.485 X-Spam-Level: X-Spam-Status: No, score=-102.485 tagged_above=-999 required=5 tests=[AWL=0.114, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ei5+VUTFiHKh; Wed, 21 Nov 2012 16:47:03 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A93EE21E8047; Wed, 21 Nov 2012 16:47:02 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.36 Message-ID: <20121122004702.13912.51647.idtracker@ietfa.amsl.com> Date: Wed, 21 Nov 2012 16:47:02 -0800 Cc: imapext@ietf.org Subject: [imapext] I-D Action: draft-ietf-imapmove-command-03.txt X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Nov 2012 00:47:03 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the IMAP MOVE extension Working Group of the = IETF. Title : Internet Message Access Protocol (IMAP) - MOVE Extension Author(s) : Arnt Gulbrandsen Ned Freed Filename : draft-ietf-imapmove-command-03.txt Pages : 9 Date : 2012-11-21 Abstract: This document defines an IMAP extension consisting of two new commands, MOVE and UID MOVE, that are used to move messages from one mailbox to another. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-imapmove-command There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-imapmove-command-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-imapmove-command-03 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From tss@iki.fi Wed Nov 21 16:59:25 2012 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5F3D21E8043 for ; Wed, 21 Nov 2012 16:59:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.531 X-Spam-Level: X-Spam-Status: No, score=-110.531 tagged_above=-999 required=5 tests=[AWL=0.068, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ghGvrc-1rdXj for ; Wed, 21 Nov 2012 16:59:25 -0800 (PST) Received: from dovecot.org (dovecot.org [193.210.130.67]) by ietfa.amsl.com (Postfix) with ESMTP id ED0A221E8040 for ; Wed, 21 Nov 2012 16:59:24 -0800 (PST) Received: from [192.168.10.101] (a88-112-255-76.elisa-laajakaista.fi [88.112.255.76]) by dovecot.org (Postfix) with ESMTP id E772E1AE8359 for ; Thu, 22 Nov 2012 02:59:23 +0200 (EET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1085) From: Timo Sirainen In-Reply-To: <20121122004702.13912.51647.idtracker@ietfa.amsl.com> Date: Thu, 22 Nov 2012 02:59:18 +0200 Content-Transfer-Encoding: 7bit Message-Id: References: <20121122004702.13912.51647.idtracker@ietfa.amsl.com> To: imapext@ietf.org X-Mailer: Apple Mail (2.1085) Subject: Re: [imapext] I-D Action: draft-ietf-imapmove-command-03.txt X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Nov 2012 00:59:26 -0000 > Note that the server may send unrelated EXPUNGE messages as well, EXPUNGEs aren't "messages". Other than that, I'm happy. From ned.freed@mrochek.com Wed Nov 21 18:22:08 2012 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9474021E8045 for ; Wed, 21 Nov 2012 18:22:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.453 X-Spam-Level: X-Spam-Status: No, score=-2.453 tagged_above=-999 required=5 tests=[AWL=0.146, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qfxs480oPdDX for ; Wed, 21 Nov 2012 18:22:08 -0800 (PST) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id 2F8CF21E8044 for ; Wed, 21 Nov 2012 18:22:08 -0800 (PST) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OMW77A9UDS0024V6@mauve.mrochek.com> for imapext@ietf.org; Wed, 21 Nov 2012 18:17:05 -0800 (PST) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OMGB2WUMLC00008S@mauve.mrochek.com>; Wed, 21 Nov 2012 18:17:03 -0800 (PST) Message-id: <01OMW778R26M00008S@mauve.mrochek.com> Date: Wed, 21 Nov 2012 18:14:14 -0800 (PST) From: Ned Freed In-reply-to: "Your message dated Thu, 22 Nov 2012 02:59:18 +0200" MIME-version: 1.0 Content-type: TEXT/PLAIN References: <20121122004702.13912.51647.idtracker@ietfa.amsl.com> To: Timo Sirainen Cc: imapext@ietf.org Subject: Re: [imapext] I-D Action: draft-ietf-imapmove-command-03.txt X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Nov 2012 02:22:08 -0000 > > Note that the server may send unrelated EXPUNGE messages as well, > EXPUNGEs aren't "messages". Other than that, I'm happy. Yep, and that error appears in several different places. I'll change them to "responses" in the next update. There's also a "for" that should be an "or". Nice catch. Ned From slusarz@horde.org Wed Nov 21 19:28:22 2012 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A98221E8053 for ; Wed, 21 Nov 2012 19:28:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.399 X-Spam-Level: X-Spam-Status: No, score=-0.399 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W+S9bpInZNi9 for ; Wed, 21 Nov 2012 19:28:21 -0800 (PST) Received: from qmta01.emeryville.ca.mail.comcast.net (qmta01.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:43:76:96:30:16]) by ietfa.amsl.com (Postfix) with ESMTP id C608D21E8048 for ; Wed, 21 Nov 2012 19:28:21 -0800 (PST) Received: from omta22.emeryville.ca.mail.comcast.net ([76.96.30.89]) by qmta01.emeryville.ca.mail.comcast.net with comcast id STC71k0091vN32cA1TUMj3; Thu, 22 Nov 2012 03:28:21 +0000 Received: from bigworm.curecanti.org ([71.229.167.0]) by omta22.emeryville.ca.mail.comcast.net with comcast id STUK1k00K00qwSn8iTUKi7; Thu, 22 Nov 2012 03:28:20 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by bigworm.curecanti.org (Postfix) with ESMTP id C201513037 for ; Wed, 21 Nov 2012 20:28:18 -0700 (MST) Received: from schrute.curecanti.org (schrute.curecanti.org [172.18.5.4]) by bigworm.curecanti.org (Horde Framework) with HTTP; Wed, 21 Nov 2012 20:28:18 -0700 Date: Wed, 21 Nov 2012 20:28:18 -0700 Message-ID: <20121121202818.Horde.zzCtkIZYRDml7Ro85HTocA4@bigworm.curecanti.org> From: Michael M Slusarz To: imapext@ietf.org References: <20121122004702.13912.51647.idtracker@ietfa.amsl.com> In-Reply-To: <20121122004702.13912.51647.idtracker@ietfa.amsl.com> User-Agent: Internet Messaging Program (IMP) H5 (6.0.2-git) Accept-Language: en X-Originating-IP: 172.18.5.4 X-Remote-Browser: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Firefox/17.0 Content-Type: text/plain; charset=UTF-8; format=flowed; DelSp=Yes MIME-Version: 1.0 Content-Disposition: inline DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1353554901; bh=J5miBVD/hC4Oxo/w+eXjjSxvJxnPK9gMDDomJdiMqa4=; h=Received:Received:Received:Received:Date:Message-ID:From:To: Subject:Content-Type:MIME-Version; b=bhPvOKT8IfLcqpkdXFL9mxc0AJT5TzPOyVxzuZUToW4eifz/J0qi0jCSGqHHtc4ca 3eLAsa/4W28EIbEYWRJep28ZxQK4HpOMPHYDzV++oYlodP3nCNJRTIPxlzZYXqzhr5 OuqjOvAAjspdlT7R+MgRaH/j5DXRmWNODEfwZS9SXl58XjJfUIW0a9RhAQjgQEVoE8 PBePBoSjlErhn4r7D5drN61nlRtBkEU3Uu8lWMYQxdsAanLF94SWfnFYvOc5IFfSKY nKxAOf5vZRtQW7f3zbxRTSg9dQqqBGdKX+nApYk87xnO4DcoohjxNpZLuwpHY1AKda 2h9ThlKwoQNMA== Subject: Re: [imapext] I-D Action: draft-ietf-imapmove-command-03.txt X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Nov 2012 03:28:22 -0000 The QRESYNC language that was changed since -02 (Section 4.4) is still a bit funky: The QRESYNC extension [RFC5162] states that the server SHOULD send VANISHED rather than the EXPUNGE in response to the UID EXPUNGE command. "the" before EXPUNGE is unnecessary and confusing. This seems more appropriate: The QRESYNC extension [RFC5162] states that the server SHOULD send VANISHED rather than EXPUNGE in response to the UID EXPUNGE command. The same issue affects Section 4.2 ("the UID MOVE"): The ACL rights [RFC4314] required for the UID MOVE are the union of the ACL rights required for UID STORE, UID COPY and UID EXPUNGE. This should probably be: The ACL rights [RFC4314] required for UID MOVE are the union of the ACL rights required for UID STORE, UID COPY and UID EXPUNGE. -or- The ACL rights [RFC4314] required for the UID MOVE command are the union of the ACL rights required for UID STORE, UID COPY and UID EXPUNGE. michael ___________________________________ Michael Slusarz [slusarz@horde.org] From ned.freed@mrochek.com Wed Nov 21 23:51:07 2012 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 210FD21F8573 for ; Wed, 21 Nov 2012 23:51:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.459 X-Spam-Level: X-Spam-Status: No, score=-2.459 tagged_above=-999 required=5 tests=[AWL=0.140, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dR4oT0ZrpmDf for ; Wed, 21 Nov 2012 23:51:06 -0800 (PST) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id 1CB7221F8543 for ; Wed, 21 Nov 2012 23:51:05 -0800 (PST) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OMWIP4IR40001ZIC@mauve.mrochek.com> for imapext@ietf.org; Wed, 21 Nov 2012 23:46:03 -0800 (PST) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OMGB2WUMLC00008S@mauve.mrochek.com>; Wed, 21 Nov 2012 23:46:01 -0800 (PST) Message-id: <01OMWIP30AW800008S@mauve.mrochek.com> Date: Wed, 21 Nov 2012 23:41:53 -0800 (PST) From: Ned Freed In-reply-to: "Your message dated Wed, 21 Nov 2012 20:28:18 -0700" <20121121202818.Horde.zzCtkIZYRDml7Ro85HTocA4@bigworm.curecanti.org> MIME-version: 1.0 Content-type: TEXT/PLAIN; Format=flowed; DelSp=Yes References: <20121122004702.13912.51647.idtracker@ietfa.amsl.com> <20121121202818.Horde.zzCtkIZYRDml7Ro85HTocA4@bigworm.curecanti.org> To: Michael M Slusarz Cc: imapext@ietf.org Subject: Re: [imapext] I-D Action: draft-ietf-imapmove-command-03.txt X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Nov 2012 07:51:07 -0000 This all seems reasonable. However, given where we are with this I'd normally leave these sorts of editorial changes to the RFC Editor. But since another update is needed for other reasons, I'll go ahead and make these changes too. Ned > The QRESYNC language that was changed since -02 (Section 4.4) is still > a bit funky: > The QRESYNC extension [RFC5162] states that the server SHOULD send > VANISHED rather than the EXPUNGE in response to the UID EXPUNGE > command. > "the" before EXPUNGE is unnecessary and confusing. This seems more > appropriate: > The QRESYNC extension [RFC5162] states that the server SHOULD send > VANISHED rather than EXPUNGE in response to the UID EXPUNGE command. > The same issue affects Section 4.2 ("the UID MOVE"): > The ACL rights [RFC4314] required for the UID MOVE are the union of > the ACL rights required for UID STORE, UID COPY and UID EXPUNGE. > This should probably be: > The ACL rights [RFC4314] required for UID MOVE are the union of > the ACL rights required for UID STORE, UID COPY and UID EXPUNGE. > -or- > The ACL rights [RFC4314] required for the UID MOVE command are the union of > the ACL rights required for UID STORE, UID COPY and UID EXPUNGE. > michael > ___________________________________ > Michael Slusarz [slusarz@horde.org] > _______________________________________________ > imapext mailing list > imapext@ietf.org > https://www.ietf.org/mailman/listinfo/imapext From barryleiba@gmail.com Sat Nov 24 06:42:44 2012 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9024021F84C0; Sat, 24 Nov 2012 06:42:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.677 X-Spam-Level: X-Spam-Status: No, score=-102.677 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_45=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PbXmYr0WttIc; Sat, 24 Nov 2012 06:42:44 -0800 (PST) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id A0C2521F84B6; Sat, 24 Nov 2012 06:42:43 -0800 (PST) Received: by mail-vb0-f44.google.com with SMTP id fc26so2254309vbb.31 for ; Sat, 24 Nov 2012 06:42:43 -0800 (PST) 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=ox8SGDfSOLBSfQeozfPdzuENrVcYl5bx8q8OVhhDEEM=; b=LP2TKayKBS5CgtHWOCsrJxDaiFvcXFUEjj+EganUQvmnffKzfkZuwNQK9KQtQFi/4d eTn9967AScnCprgqs7f5SH4sAFtBvOgffMZZcuHYku7VAgwdT+/JRPBqjzyNoWhlrzCU aMlkKsjShSmzd300j3SLeAXXQrmb2T6FyHawVpooBJU1f3CDtRxj2mHGemb6f/NcLFOo juc1aBCuD4NNa4pmgpPT7taBDJ1CMumWOSQoNw/Jtp4MgXlFPHTfGO8TEk0kaa3fAHqb LWCZ1Ql0/1QISySuJEGfNWF0pYbJOAUrNrbzBsA8Qd3C3l0H0a0VuIYk0kFi7s4UJUXX cPBA== MIME-Version: 1.0 Received: by 10.220.16.4 with SMTP id m4mr10551432vca.43.1353768163054; Sat, 24 Nov 2012 06:42:43 -0800 (PST) Sender: barryleiba@gmail.com Received: by 10.58.28.231 with HTTP; Sat, 24 Nov 2012 06:42:42 -0800 (PST) In-Reply-To: <20121123220800.12283.82353.idtracker@ietfa.amsl.com> References: <20121123220800.12283.82353.idtracker@ietfa.amsl.com> Date: Sat, 24 Nov 2012 09:42:42 -0500 X-Google-Sender-Auth: f9VFntAIIzZeDZyPPyawvVUa49Q Message-ID: From: Barry Leiba To: Pete Resnick Content-Type: text/plain; charset=ISO-8859-1 Cc: imapmove-chairs@tools.ietf.org, draft-ietf-imapmove-command@tools.ietf.org, The IESG , "imapext@ietf.org" Subject: Re: [imapext] Pete Resnick's Discuss on draft-ietf-imapmove-command-03: (with DISCUSS and COMMENT) X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Nov 2012 14:42:44 -0000 I'm adding the working group mailing list to this, because I think it needs to be aired there. > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > I have not been following this WG, and I might have the Sieve bit wrong, > so I apologize in advance if this issue has been considered and addressed > by the WG; if so, I will remove this DISCUSS immediately. But this causes > me concern: > > Section 4.5: > > Because MOVE does not cause flags > to be changed, a MOVE command will not result in a script invocation > with the imap.cause set to "FLAG". > > I think this is either wrong or needs more explanation. Section section > 3.3 is clear that doing a move "has the same effect for each message > as...[UID] STORE +FLAGS.SILENT \DELETED", which the above seems to > contradict. But even this is intended, I would think this would at the > very least cause significant user surprise: In a current client, if I > choose the "move" command in the UI, I'm going to get an invocation for > the COPY on the destination message *and* an invocation for the STORE > \DELETED on the source message. You are saying that an upgraded client > that starts using "MOVE" for it's "move" command will suddenly stop > invoking for the deletion. If you *don't* want Sieve to invoke for the > flag change, I think you're going to have to add a new imap.cause of > either MOVE or EXPUNGE, and folks will have to go rewrite their scripts. > But I would think the easier route would be to get a second invocation > from MOVE with imap.cause set to "FLAG". There appear to be two points here: 1. The MOVE spec is saying that in the end, the MOVE command has the same effect as the COPY/STORE/EXPUNGE sequence that clients are doing today. It does NOT mean that the MOVE command is equivalent to that sequence in every way, including intermediate states. It's precisely the purpose of making it a single command that we get away from the intermediate state problem, and allow servers to optimize a MOVE over a COPY/DELETE function. We absolutely do NOT want to make servers present that "\Deleted flag is set" state in any context. 2. We did discuss, though only very briefly, whether to have a separate imapsieve cause for this, and decided that it wasn't worth the complexity. No one has a use case for needing it. If you do, we'd like to hear it.. Perhaps there might be a use case if, say, one wanted to use a Sieve script to take any message that was being removed from the inbox and do "fileinto Archive" on it. That use case would be marginal now, because there's no imapsieve event for expunge (only for the flag change on \Deleted), and no way in Sieve to remove a message from Archive, so constantly setting and resetting the \Deleted flag, without ever expunging, would just cause the message to be repeatedly re-filed into Archive. But anyway, if we accept some use case like that, we might need something here. But it gets complicated. The COPY cause is run against the target mailbox only. We'd have to have a new cause that's run against the source mailbox in *addition* to that. Say, a MOVE (out of) cause that's run against the source mailbox's script before the move, and then a COPY (into) cause that's run against the target mailbox's script after the move. And then we'd have to ask whether there's a need for a new environment variable to name the other mailbox that's involved (we had no use case to do this for the COPY cause, so we didn't), because we might want to know where it was being moved TO, or where it's being copied FROM, for processing in the script. As I said, no one wanted the extra complication, and no one had a use case for needing it. > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Section 1: > > Purely editorial nonsense: > > clients have instead had to use a combination of the UID STORE, UID > COPY and EXPUNGE commands to perform this very common operation. > > Seems to me that you should list the commands without the UID (since > they're not required) and in the right order. So instead: > > clients have instead had to use a combination of the COPY, STORE, > and EXPUNGE commands to perform this very common operation. > > And if you have any reason for keeping the original, do so. Just one AD's > OCD. That's probably an appropriate change -- the UID versions are a vestige of the original spec, which ONLY had UID MOVE, and did not define a non-UID version. Barry From ned.freed@mrochek.com Sat Nov 24 11:58:52 2012 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF80B21F84F0; Sat, 24 Nov 2012 11:58:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[AWL=-1.095, BAYES_20=-0.74, J_CHICKENPOX_45=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Is5qkLIQlan7; Sat, 24 Nov 2012 11:58:52 -0800 (PST) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id 1011621F84C6; Sat, 24 Nov 2012 11:58:52 -0800 (PST) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01ON00P1BB6O001ZU9@mauve.mrochek.com>; Sat, 24 Nov 2012 11:53:45 -0800 (PST) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OMYK62328G00008T@mauve.mrochek.com>; Sat, 24 Nov 2012 11:53:40 -0800 (PST) Message-id: <01ON00OXRTL600008T@mauve.mrochek.com> Date: Sat, 24 Nov 2012 11:36:45 -0800 (PST) From: Ned Freed In-reply-to: "Your message dated Sat, 24 Nov 2012 09:42:42 -0500" MIME-version: 1.0 Content-type: TEXT/PLAIN References: <20121123220800.12283.82353.idtracker@ietfa.amsl.com> To: Barry Leiba Cc: imapmove-chairs@tools.ietf.org, draft-ietf-imapmove-command@tools.ietf.org, Pete Resnick , The IESG , "imapext@ietf.org" Subject: Re: [imapext] Pete Resnick's Discuss on draft-ietf-imapmove-command-03: (with DISCUSS and COMMENT) X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Nov 2012 19:58:53 -0000 > I'm adding the working group mailing list to this, because I think it > needs to be aired there. > > ---------------------------------------------------------------------- > > DISCUSS: > > ---------------------------------------------------------------------- > > > > I have not been following this WG, and I might have the Sieve bit wrong, > > so I apologize in advance if this issue has been considered and addressed > > by the WG; if so, I will remove this DISCUSS immediately. But this causes > > me concern: > > > > Section 4.5: > > > > Because MOVE does not cause flags > > to be changed, a MOVE command will not result in a script invocation > > with the imap.cause set to "FLAG". > > > > I think this is either wrong or needs more explanation. Section section > > 3.3 is clear that doing a move "has the same effect for each message > > as...[UID] STORE +FLAGS.SILENT \DELETED", which the above seems to > > contradict. But even this is intended, I would think this would at the > > very least cause significant user surprise: In a current client, if I > > choose the "move" command in the UI, I'm going to get an invocation for > > the COPY on the destination message *and* an invocation for the STORE > > \DELETED on the source message. You are saying that an upgraded client > > that starts using "MOVE" for it's "move" command will suddenly stop > > invoking for the deletion. If you *don't* want Sieve to invoke for the > > flag change, I think you're going to have to add a new imap.cause of > > either MOVE or EXPUNGE, and folks will have to go rewrite their scripts. > > But I would think the easier route would be to get a second invocation > > from MOVE with imap.cause set to "FLAG". > There appear to be two points here: > 1. The MOVE spec is saying that in the end, the MOVE command has the > same effect as the COPY/STORE/EXPUNGE sequence that clients are doing > today. It does NOT mean that the MOVE command is equivalent to that > sequence in every way, including intermediate states. It's precisely > the purpose of making it a single command that we get away from the > intermediate state problem, and allow servers to optimize a MOVE over > a COPY/DELETE function. Yes, and we've been struggling with how to present this from the start. The fact that Pete misunderstood this suggests that the document still isn't clear about some aspects of this. (See below for some suggested text.) > We absolutely do NOT want to make servers present that "\Deleted flag > is set" state in any context. Absolutely. Perhaps we need to add something like this before the third paragraph in section 3.3: Although the effect of MOVE is the same as the preceeding steps, the intermediate states produced by those steps do not occur. In particular, at no time will the \DELETED flag be seen to be set. > 2. We did discuss, though only very briefly, whether to have a > separate imapsieve cause for this, and decided that it wasn't worth > the complexity. No one has a use case for needing it. If you do, > we'd like to hear it.. Specifically, I brought up the idea of a "MOVE" cause. Nobody seemed interested in it. > Perhaps there might be a use case if, say, one wanted to use a Sieve > script to take any message that was being removed from the inbox and > do "fileinto Archive" on it. That use case would be marginal now, > because there's no imapsieve event for expunge (only for the flag > change on \Deleted), and no way in Sieve to remove a message from > Archive, so constantly setting and resetting the \Deleted flag, > without ever expunging, would just cause the message to be repeatedly > re-filed into Archive. But anyway, if we accept some use case like > that, we might need something here. > But it gets complicated. > The COPY cause is run against the target mailbox only. We'd have to > have a new cause that's run against the source mailbox in *addition* > to that. Say, a MOVE (out of) cause that's run against the source > mailbox's script before the move, and then a COPY (into) cause that's > run against the target mailbox's script after the move. And then we'd > have to ask whether there's a need for a new environment variable to > name the other mailbox that's involved (we had no use case to do this > for the COPY cause, so we didn't), because we might want to know where > it was being moved TO, or where it's being copied FROM, for processing > in the script. > As I said, no one wanted the extra complication, and no one had a use > case for needing it. Agreed on all points. I'm not especially happy with this result, but I'm nowhere near convinced that doing something like, say, applying a Sieve to the source mailbox with a "movefrom" cause then applying a Sieve to the target mailbox with a "moveto" cause is worth it. I am convinced, however, that exposing intemediate state, which a "flags" cause absolutely would do, would be very bad. I'll also note that Sieve in IMAP has always been a tough nut semantically. (And this really has little to do with Sieve; the semantics of IMAP weren't designed with coherent generation of mailbox events in mind.) While I think we've done a good job on Sieve in IMAP, if usage takes off I have a feeling we'll need to revisit some of the choices we've made. > > ---------------------------------------------------------------------- > > COMMENT: > > ---------------------------------------------------------------------- > > > > Section 1: > > > > Purely editorial nonsense: > > > > clients have instead had to use a combination of the UID STORE, UID > > COPY and EXPUNGE commands to perform this very common operation. > > > > Seems to me that you should list the commands without the UID (since > > they're not required) and in the right order. So instead: > > > > clients have instead had to use a combination of the COPY, STORE, > > and EXPUNGE commands to perform this very common operation. > > > > And if you have any reason for keeping the original, do so. Just one AD's > > OCD. > That's probably an appropriate change -- the UID versions are a > vestige of the original spec, which ONLY had UID MOVE, and did not > define a non-UID version. Agreed. I need to do another revision anyway; this will be in it. Ned From barryleiba@computer.org Mon Nov 26 07:03:07 2012 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9746A21F858E; Mon, 26 Nov 2012 07:03:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dQnaSjBbe8x0; Mon, 26 Nov 2012 07:03:07 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2171621F857C; Mon, 26 Nov 2012 07:03:07 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: "Barry Leiba" To: The IESG X-Test-IDTracker: no X-IETF-IDTracker: 4.36 Message-ID: <20121126150307.32380.97144.idtracker@ietfa.amsl.com> Date: Mon, 26 Nov 2012 07:03:07 -0800 Cc: imapmove-chairs@tools.ietf.org, draft-ietf-imapmove-command@tools.ietf.org, imapext@ietf.org Subject: [imapext] Barry Leiba's Discuss on draft-ietf-imapmove-command-03: (with DISCUSS) X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Nov 2012 15:03:07 -0000 Barry Leiba has entered the following ballot position for draft-ietf-imapmove-command-03: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- The last paragraph of Section 3.3 says this: Both MOVE and UID MOVE can be pipelined. However, pipelined MOVE and UID MOVE commands MUST NOT specify overlapping sets of messages. I'm not sure the "overlapping sets" is a sufficient restriction for (non-UID) MOVE. Consider a mailbox with messages having UIDs 101, 102, 103, 104, 105, 106, and 107, and this sequence: C: t1 MOVE 2:3 Apple C: t2 MOVE 4:5 Banana S: * EXPUNGE 2 S: t1 NO [SERVERBUG] the move for message 3 failed The command tagged t1 is meant to move UIDs 102 and 103. That move will cause the messages to be renumbered (leaving 101, 104, 105, 106, and 107), so that messages 4 and 5 represent UIDs 106 and 107. But because the move for message 3 (UID 103) failed, messages 4 and 5 will afterward actually be UIDs 105 and 106. I think that what this actually means is that the last two paragraphs are contradictory: The server may send EXPUNGE (or VANISHED) messages before the tagged response, so the client cannot safely send more commands with message sequence number arguments while the server is processing MOVE. The UID MOVE command does not have this limitation. Both MOVE and UID MOVE can be pipelined. However, pipelined MOVE and UID MOVE commands MUST NOT specify overlapping sets of messages. We can't have "the client cannot safely send more commands with message sequence number arguments while the server is processing MOVE," and at the same time allow the version of MOVE that uses sequence numbers to be pipelined. We might also consider a citation to RFC 3501, Section 5.5 here. From jkt@flaska.net Mon Nov 26 07:13:41 2012 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A80921F85A6 for ; Mon, 26 Nov 2012 07:13:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.3 X-Spam-Level: X-Spam-Status: No, score=-2.3 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TG6ZrvblZCFe for ; Mon, 26 Nov 2012 07:13:41 -0800 (PST) Received: from latimerie.flaska.net (latimerie.flaska.net [IPv6:2a02:2b88:2:1::4a7:333]) by ietfa.amsl.com (Postfix) with ESMTP id 3F36321F8469 for ; Mon, 26 Nov 2012 07:13:37 -0800 (PST) Received: by latimerie.flaska.net (Postfix, from userid 1000) id F15FD61C08; Mon, 26 Nov 2012 16:13:38 +0100 (CET) From: =?iso-8859-1?Q?Jan_Kundr=E1t?= To: Date: Mon, 26 Nov 2012 16:13:30 +0100 User-Agent: trojita/v0.3-1522-gd98baee; Qt/4.8.3; X11; Linux; MIME-Version: 1.0 Message-ID: <9277d93e-0d2b-47cf-b522-7fa3e246ea7c@flaska.net> In-Reply-To: <01ON00OXRTL600008T@mauve.mrochek.com> References: <20121123220800.12283.82353.idtracker@ietfa.amsl.com> <01ON00OXRTL600008T@mauve.mrochek.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Subject: [imapext] =?iso-8859-1?q?_Re=3A_Pete_Resnick=27s_Discuss_on_draft?= =?iso-8859-1?q?-ietf-imapmove-command-03=3A_=28with_DISCUSS_and_CO?= =?iso-8859-1?q?MMENT=29?= X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Nov 2012 15:13:41 -0000 On Saturday, 24 November 2012 20:36:45 CEST, Ned Freed wrote:=0A> Absol= utely. Perhaps we need to add something like this before the third=0A> = paragraph in section 3.3:=0A>=0A> Although the effect of MOVE is the= same as the preceeding steps,=0A> the intermediate states produced = by those steps do not occur. In=0A> particular, at no time will the = \DELETED flag be seen to be set.=0A=0A(Replying just to imapext, please= let me know if this should've gone to all recipients instead.)=0A=0ADo= es it mean that servers SHOULD NOT send the FLAGS \Deleted message to (= this, or any other parallel) IMAP session, or does it mean that they MU= ST NOT do so? It is not clear to me from this wording.=0A=0AWith kind r= egards,=0AJan From alexey.melnikov@isode.com Mon Nov 26 07:54:48 2012 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB61921F86B3 for ; Mon, 26 Nov 2012 07:54:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.449 X-Spam-Level: X-Spam-Status: No, score=-102.449 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j0BpRRtQ+qUH for ; Mon, 26 Nov 2012 07:54:47 -0800 (PST) Received: from waldorf.isode.com (cl-125.lon-03.gb.sixxs.net [IPv6:2a00:14f0:e000:7c::2]) by ietfa.amsl.com (Postfix) with ESMTP id C038E21F8668 for ; Mon, 26 Nov 2012 07:54:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1353945284; d=isode.com; s=selector; i=@isode.com; bh=Uc6O4rWu+7d9euTqTblhrC3vlgTH7IH/qogyVxgWhh8=; 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=rZP0qIdbRngGJi5LF/lItnZwbixHHQVL9U8GVAEdqgmI2LipCJZr0lyKM8sRgKpmB6wtfm E5EsUbXnJcuBh4Qe/oiUL3prO/SLrZYB6AnthmmlG5iFxcQu7kXjBSp5xNR0jJzcBIzZMh gvEdlKRdudhJJuphpeW47VYBZF9excQ=; Received: from [172.16.1.29] (shiny.isode.com [62.3.217.250]) by waldorf.isode.com (submission channel) via TCP with ESMTPA id ; Mon, 26 Nov 2012 15:54:44 +0000 Message-ID: <50B390FF.1010005@isode.com> Date: Mon, 26 Nov 2012 15:55:43 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 To: =?ISO-8859-1?Q?Jan_Kundr=E1t?= References: <20121123220800.12283.82353.idtracker@ietfa.amsl.com> <01ON00OXRTL600008T@mauve.mrochek.com> <9277d93e-0d2b-47cf-b522-7fa3e246ea7c@flaska.net> In-Reply-To: <9277d93e-0d2b-47cf-b522-7fa3e246ea7c@flaska.net> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: quoted-printable Cc: imapext@ietf.org Subject: Re: [imapext] Pete Resnick's Discuss on draft-ietf-imapmove-command-03: (with DISCUSS and COMMENT) X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Nov 2012 15:54:48 -0000 Hi Jan, On 26/11/2012 15:13, Jan Kundr=E1t wrote: > On Saturday, 24 November 2012 20:36:45 CEST, Ned Freed wrote: >> Absolutely. Perhaps we need to add something like this before the third >> paragraph in section 3.3: >> >> Although the effect of MOVE is the same as the preceeding steps, >> the intermediate states produced by those steps do not occur. In >> particular, at no time will the \DELETED flag be seen to be set. > > (Replying just to imapext, please let me know if this should've gone=20 > to all recipients instead.) > > Does it mean that servers SHOULD NOT send the FLAGS \Deleted message=20 > to (this, or any other parallel) IMAP session, or does it mean that=20 > they MUST NOT do so? It is not clear to me from this wording. I don't think it actually matters. If a server mistakenly sends \Deleted=20 on MOVE, it doesn't look like any harm will occur. Feel free to disagree=20 with me, of course. From presnick@qti.qualcomm.com Mon Nov 26 08:29:14 2012 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2718D21F86BB; Mon, 26 Nov 2012 08:29:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.999 X-Spam-Level: X-Spam-Status: No, score=-101.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_45=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4y7PsZfkeF75; Mon, 26 Nov 2012 08:29:13 -0800 (PST) Received: from sabertooth02.qualcomm.com (sabertooth02.qualcomm.com [65.197.215.38]) by ietfa.amsl.com (Postfix) with ESMTP id 42D6E21F862E; Mon, 26 Nov 2012 08:29:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1353945831; x=1385481831; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=tSX+uH1vFEnGoIamegypzpp3D1MdVHBfsoqZx2vjiWs=; b=slDb7/VWHVlaoevMgx+fWzb7ZjRAqOxneOKX6Fa7nYRHV2KsJBcS4gdc GWOSBREyhwib290F4Jddq7GLfYXT6y416/zBDmDZ/mkYS8FdtNawMZDLZ oQihmcfHZ5bv+h7FWds96/+tpU9h+9XMv1Ct7jie0gf5c3YtaVG3C+Mp4 I=; X-IronPort-AV: E=McAfee;i="5400,1158,6907"; a="9011811" Received: from ironmsg02-lv.qualcomm.com ([10.47.202.183]) by sabertooth02.qualcomm.com with ESMTP; 26 Nov 2012 08:03:50 -0800 X-IronPort-AV: E=McAfee;i="5400,1158,6907"; a="2436079" Received: from nasanexhc07.na.qualcomm.com ([172.30.39.190]) by ironmsg02-lv.qualcomm.com with ESMTP/TLS/RC4-SHA; 26 Nov 2012 08:29:11 -0800 Received: from presnick-mac.local (172.30.39.5) by qcmail1.qualcomm.com (172.30.39.190) with Microsoft SMTP Server (TLS) id 14.2.318.4; Mon, 26 Nov 2012 08:29:11 -0800 Message-ID: <50B398D4.7050402@qti.qualcomm.com> Date: Mon, 26 Nov 2012 10:29:08 -0600 From: Pete Resnick User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.7; en-US; rv:1.9.1.9) Gecko/20100630 Eudora/3.0.4 MIME-Version: 1.0 To: Ned Freed References: <20121123220800.12283.82353.idtracker@ietfa.amsl.com> <01ON00OXRTL600008T@mauve.mrochek.com> In-Reply-To: <01ON00OXRTL600008T@mauve.mrochek.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [172.30.39.5] Cc: imapmove-chairs@tools.ietf.org, draft-ietf-imapmove-command@tools.ietf.org, Barry Leiba , The IESG , "imapext@ietf.org" Subject: Re: [imapext] Pete Resnick's Discuss on draft-ietf-imapmove-command-03: (with DISCUSS and COMMENT) X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Nov 2012 16:29:14 -0000 On 11/24/12 1:36 PM, Ned Freed wrote: >>> Section 4.5: >>> >>> Because MOVE does not cause flags >>> to be changed, a MOVE command will not result in a script invocation >>> with the imap.cause set to "FLAG". >>> >>> I think this is either wrong or needs more explanation. Section section >>> 3.3 is clear that doing a move "has the same effect for each message >>> as...[UID] STORE +FLAGS.SILENT \DELETED", which the above seems to >>> contradict. But even this is intended, I would think this would at the >>> very least cause significant user surprise: In a current client, if I >>> choose the "move" command in the UI, I'm going to get an invocation for >>> the COPY on the destination message *and* an invocation for the STORE >>> \DELETED on the source message. You are saying that an upgraded client >>> that starts using "MOVE" for it's "move" command will suddenly stop >>> invoking for the deletion. If you *don't* want Sieve to invoke for the >>> flag change, I think you're going to have to add a new imap.cause of >>> either MOVE or EXPUNGE, and folks will have to go rewrite their scripts. >>> But I would think the easier route would be to get a second invocation >>> from MOVE with imap.cause set to "FLAG". >>> >> We absolutely do NOT want to make servers present that "\Deleted flag >> is set" state in any context. >> > Absolutely. Perhaps we need to add something like this before the third > paragraph in section 3.3: > > Although the effect of MOVE is the same as the preceeding steps, > the intermediate states produced by those steps do not occur. In > particular, at no time will the \DELETED flag be seen to be set. > If you're going this route, maybe even a bit more would be useful: Although the effect of the MOVE is the same as the preceding steps, the semantics are not identical: The intermediate states produced by those steps do not occur, and the response codes are different. In particular, though the COPY and EXPUNGE response codes will return, no response code for a STORE will be generated nor will the \DELETED flag be set for any message. Too much? >> 2. We did discuss, though only very briefly, whether to have a >> separate imapsieve cause for this, and decided that it wasn't worth >> the complexity. No one has a use case for needing it. If you do, >> we'd like to hear it.. >> > Specifically, I brought up the idea of a "MOVE" cause. Nobody seemed interested > in it. And it's tricky: I mentioned an EXPUNGE cause above, but that would have to trigger before the message was actually gone from the original mailbox (because otherwise you wouldn't have access to the message that just got expunged). A MOVE clause is a little better since you would have access to the destination message. But if nobody is interested, so be it. >> As I said, no one wanted the extra complication, and no one had a use >> case for needing it. >> > Agreed on all points. I'm not especially happy with this result, but I'm > nowhere near convinced that doing something like, say, applying a Sieve to the > source mailbox with a "movefrom" cause then applying a Sieve to the target > mailbox with a "moveto" cause is worth it. I am convinced, however, that > exposing intemediate state, which a "flags" cause absolutely would do, would be > very bad. > I presume you don't want the intermediate state because it would make the command non-atomic? Yup, I guess so. :-/ OK, I'll clear the DISCUSS and note the change in the COMMENT. Thanks. pr -- Pete Resnick Qualcomm Technologies, Inc. - +1 (858)651-4478 From cyrus@daboo.name Mon Nov 26 08:44:34 2012 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 603CF21F8588 for ; Mon, 26 Nov 2012 08:44:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.299 X-Spam-Level: X-Spam-Status: No, score=-102.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5W+U9Zufye7O for ; Mon, 26 Nov 2012 08:44:33 -0800 (PST) Received: from daboo.name (daboo.name [173.13.55.49]) by ietfa.amsl.com (Postfix) with ESMTP id BB66121F85AB for ; Mon, 26 Nov 2012 08:44:33 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by daboo.name (Postfix) with ESMTP id 877AB364478E; Mon, 26 Nov 2012 11:44:28 -0500 (EST) X-Virus-Scanned: amavisd-new at example.com Received: from daboo.name ([127.0.0.1]) by localhost (daboo.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Aqsa8-vlVryS; Mon, 26 Nov 2012 11:44:28 -0500 (EST) Received: from caldav.corp.apple.com (unknown [17.45.162.46]) by daboo.name (Postfix) with ESMTPSA id D0A5C3644783; Mon, 26 Nov 2012 11:44:26 -0500 (EST) Date: Mon, 26 Nov 2012 11:44:23 -0500 From: Cyrus Daboo To: Alexey Melnikov , =?UTF-8?Q?Jan_Kundr=C3=A1t?= Message-ID: <67067840A8B50E4E45AC9499@caldav.corp.apple.com> In-Reply-To: <50B390FF.1010005@isode.com> References: <20121123220800.12283.82353.idtracker@ietfa.amsl.com> <01ON00OXRTL600008T@mauve.mrochek.com> <9277d93e-0d2b-47cf-b522-7fa3e246ea7c@flaska.net> <50B390FF.1010005@isode.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=888 Cc: imapext@ietf.org Subject: Re: [imapext] Pete Resnick's Discuss on draft-ietf-imapmove-command-03: (with DISCUSS and COMMENT) X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Nov 2012 16:44:34 -0000 Hi Alexey, --On November 26, 2012 3:55:43 PM +0000 Alexey Melnikov wrote: >> Does it mean that servers SHOULD NOT send the FLAGS \Deleted message >> to (this, or any other parallel) IMAP session, or does it mean that >> they MUST NOT do so? It is not clear to me from this wording. > > I don't think it actually matters. If a server mistakenly sends \Deleted > on MOVE, it doesn't look like any harm will occur. Feel free to disagree > with me, of course. If we can I think we need to say "servers MUST NOT send unsolicited FLAGS \Deleted messages in other client sessions that have the mailbox selected, only EXPUNGED or VANISHED are sent". Why? Well scalability - if a user moves 1000 messages (something I occasionally do when "archiving" messages), having 1000 unsolicited deletes go to other clients is a waste of bandwidth/cpu. -- Cyrus Daboo From ned.freed@mrochek.com Mon Nov 26 09:15:03 2012 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6428321F850B for ; Mon, 26 Nov 2012 09:15:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vPPsQhSG4k0z for ; Mon, 26 Nov 2012 09:15:03 -0800 (PST) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id F053521F8514 for ; Mon, 26 Nov 2012 09:15:02 -0800 (PST) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01ON2NJPYHSW00272S@mauve.mrochek.com> for imapext@ietf.org; Mon, 26 Nov 2012 09:10:00 -0800 (PST) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OMYK62328G00008T@mauve.mrochek.com>; Mon, 26 Nov 2012 09:09:57 -0800 (PST) Message-id: <01ON2NJO8WPE00008T@mauve.mrochek.com> Date: Mon, 26 Nov 2012 08:10:04 -0800 (PST) From: Ned Freed In-reply-to: "Your message dated Mon, 26 Nov 2012 16:13:30 +0100" <9277d93e-0d2b-47cf-b522-7fa3e246ea7c@flaska.net> MIME-version: 1.0 Content-type: TEXT/PLAIN; Format=flowed References: <20121123220800.12283.82353.idtracker@ietfa.amsl.com> <01ON00OXRTL600008T@mauve.mrochek.com> <9277d93e-0d2b-47cf-b522-7fa3e246ea7c@flaska.net> To: =?iso-8859-1?Q?Jan_Kundr=E1t?= Cc: imapext@ietf.org Subject: Re: [imapext] =?iso-8859-1?q?Pete_Resnick=27s_Discuss_on_draft-ietf-i?= =?iso-8859-1?q?mapmove-command-03=3A_=28with_DISCUSS_and_COMMENT=29?= X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Nov 2012 17:15:03 -0000 > On Saturday, 24 November 2012 20:36:45 CEST, Ned Freed wrote: > > Absolutely. Perhaps we need to add something like this before the third > > paragraph in section 3.3: > > > > Although the effect of MOVE is the same as the preceeding steps, > > the intermediate states produced by those steps do not occur. In > > particular, at no time will the \DELETED flag be seen to be set. > (Replying just to imapext, please let me know if this should've gone to all recipients instead.) > Does it mean that servers SHOULD NOT send the FLAGS \Deleted message to > (this, or any other parallel) IMAP session, or does it mean that they MUST NOT > do so? It is not clear to me from this wording. I have no idea what "send" a "message" means in this context. The text says that the \Deleted flag must not be visibly set at any time during the operation. We can use compliance language for that to make it cleaer, but what happens inside the server is not our concern and should not be specified. Ned From jkt@flaska.net Mon Nov 26 09:28:06 2012 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C83D721F85FC for ; Mon, 26 Nov 2012 09:28:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.3 X-Spam-Level: X-Spam-Status: No, score=-2.3 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZqTS4hAlkuH7 for ; Mon, 26 Nov 2012 09:28:06 -0800 (PST) Received: from latimerie.flaska.net (latimerie.flaska.net [IPv6:2a02:2b88:2:1::4a7:333]) by ietfa.amsl.com (Postfix) with ESMTP id 43F0F21F85EE for ; Mon, 26 Nov 2012 09:28:06 -0800 (PST) Received: by latimerie.flaska.net (Postfix, from userid 1000) id 3567C61C0C; Mon, 26 Nov 2012 18:28:08 +0100 (CET) From: =?iso-8859-1?Q?Jan_Kundr=E1t?= To: Date: Mon, 26 Nov 2012 18:27:59 +0100 User-Agent: trojita/v0.3-1522-gd98baee; Qt/4.8.3; X11; Linux; MIME-Version: 1.0 Message-ID: <21301df8-ae55-400d-985c-847cae5fc4ee@flaska.net> In-Reply-To: <01ON2NJO8WPE00008T@mauve.mrochek.com> References: <20121123220800.12283.82353.idtracker@ietfa.amsl.com> <01ON00OXRTL600008T@mauve.mrochek.com> <9277d93e-0d2b-47cf-b522-7fa3e246ea7c@flaska.net> <01ON2NJO8WPE00008T@mauve.mrochek.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Subject: [imapext] =?iso-8859-1?q?_Re=3A_Pete_Resnick=27s_Discuss_on_draft?= =?iso-8859-1?q?-ietf-imapmove-command-03=3A_=28with_DISCUSS_and_CO?= =?iso-8859-1?q?MMENT=29?= X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Nov 2012 17:28:06 -0000 On Monday, 26 November 2012 17:10:04 CEST, Ned Freed wrote:=0A> I have = no idea what "send" a "message" means in this context. The text =0A> sa= ys=0A> that the \Deleted flag must not be visibly set at any time durin= g the=0A> operation. We can use compliance language for that to make it= =0A> cleaer, but what=0A> happens inside the server is not our concern= and should not be specified. =0A=0AUsing SHOULD NOT or MUST NOT is wha= t I was requesting.=0A=0AAnd for the record, my understanding of draft-= ietf-imapmove-command-03 (as posted on IETF's website) is that it does = not say anything about this visibility of the immediate state (which me= ans that it was allowed). I support this change and hope it isn't a too= strict requirement for the implementors. In particular, as a client au= thor, I'd prefer to send UID MOVE to a server which returns me back use= less FLAGS \Deleted response than send three command myself. From my po= int of view, having a SHOULD NOT is fine with me.=0A=0AWith kind regard= s,=0AJan From ned.freed@mrochek.com Mon Nov 26 11:39:32 2012 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02D7B21F8528 for ; Mon, 26 Nov 2012 11:39:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.524 X-Spam-Level: X-Spam-Status: No, score=-2.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uwSkxnal0hzA for ; Mon, 26 Nov 2012 11:39:30 -0800 (PST) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id 619B821F84C1 for ; Mon, 26 Nov 2012 11:39:26 -0800 (PST) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01ON2SLJKR8W001PUD@mauve.mrochek.com> for imapext@ietf.org; Mon, 26 Nov 2012 11:34:15 -0800 (PST) MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=iso-8859-1; Format=flowed Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01ON2R5SZHSG00008T@mauve.mrochek.com>; Mon, 26 Nov 2012 11:34:12 -0800 (PST) Message-id: <01ON2SLHUUX200008T@mauve.mrochek.com> Date: Mon, 26 Nov 2012 11:31:14 -0800 (PST) From: Ned Freed In-reply-to: "Your message dated Mon, 26 Nov 2012 15:55:43 +0000" <50B390FF.1010005@isode.com> References: <20121123220800.12283.82353.idtracker@ietfa.amsl.com> <01ON00OXRTL600008T@mauve.mrochek.com> <9277d93e-0d2b-47cf-b522-7fa3e246ea7c@flaska.net> <50B390FF.1010005@isode.com> To: Alexey Melnikov Cc: =?ISO-8859-1?Q?Jan_Kundr=E1t?= , imapext@ietf.org Subject: Re: [imapext] Pete Resnick's Discuss on draft-ietf-imapmove-command-03: (with DISCUSS and COMMENT) X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Nov 2012 19:39:32 -0000 > Hi Jan, > On 26/11/2012 15:13, Jan Kundrát wrote: > > On Saturday, 24 November 2012 20:36:45 CEST, Ned Freed wrote: > >> Absolutely. Perhaps we need to add something like this before the third > >> paragraph in section 3.3: > >> > >> Although the effect of MOVE is the same as the preceeding steps, > >> the intermediate states produced by those steps do not occur. In > >> particular, at no time will the \DELETED flag be seen to be set. > > > > (Replying just to imapext, please let me know if this should've gone > > to all recipients instead.) > > > > Does it mean that servers SHOULD NOT send the FLAGS \Deleted message > > to (this, or any other parallel) IMAP session, or does it mean that > > they MUST NOT do so? It is not clear to me from this wording. > I don't think it actually matters. If a server mistakenly sends \Deleted > on MOVE, it doesn't look like any harm will occur. Feel free to disagree > with me, of course. Cyrus described one case where it matters. Another is the Sieve interfation: Sending out a \DELETED flag change without running the Sieve with a flag change cause creates a silly state. I'm strongly inclined to go with a MUST NOT here. Ned From ned.freed@mrochek.com Mon Nov 26 13:59:00 2012 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FB1321F8641; Mon, 26 Nov 2012 13:59:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.549 X-Spam-Level: X-Spam-Status: No, score=-2.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 047TGZVyKSPV; Mon, 26 Nov 2012 13:59:00 -0800 (PST) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id 1629521F863B; Mon, 26 Nov 2012 13:59:00 -0800 (PST) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01ON2XGRQIPC002DE9@mauve.mrochek.com>; Mon, 26 Nov 2012 13:53:57 -0800 (PST) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01ON2R5SZHSG00008T@mauve.mrochek.com>; Mon, 26 Nov 2012 13:53:54 -0800 (PST) Message-id: <01ON2XGPWZGO00008T@mauve.mrochek.com> Date: Mon, 26 Nov 2012 13:40:52 -0800 (PST) From: Ned Freed In-reply-to: "Your message dated Mon, 26 Nov 2012 07:03:07 -0800" <20121126150307.32380.97144.idtracker@ietfa.amsl.com> MIME-version: 1.0 Content-type: TEXT/PLAIN References: <20121126150307.32380.97144.idtracker@ietfa.amsl.com> To: Barry Leiba Cc: imapmove-chairs@tools.ietf.org, draft-ietf-imapmove-command@tools.ietf.org, The IESG , imapext@ietf.org Subject: Re: [imapext] Barry Leiba's Discuss on draft-ietf-imapmove-command-03: (with DISCUSS) X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Nov 2012 21:59:00 -0000 > Barry Leiba has entered the following ballot position for > draft-ietf-imapmove-command-03: Discuss > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > The last paragraph of Section 3.3 says this: > Both MOVE and UID MOVE can be pipelined. However, pipelined MOVE and > UID MOVE commands MUST NOT specify overlapping sets of messages. > I'm not sure the "overlapping sets" is a sufficient restriction for > (non-UID) MOVE. Consider a mailbox with messages having UIDs 101, 102, > 103, 104, 105, 106, and 107, and this sequence: > C: t1 MOVE 2:3 Apple > C: t2 MOVE 4:5 Banana > S: * EXPUNGE 2 > S: t1 NO [SERVERBUG] the move for message 3 failed > The command tagged t1 is meant to move UIDs 102 and 103. That move will > cause the messages to be renumbered (leaving 101, 104, 105, 106, and > 107), so that messages 4 and 5 represent UIDs 106 and 107. But because > the move for message 3 (UID 103) failed, messages 4 and 5 will afterward > actually be UIDs 105 and 106. > I think that what this actually means is that the last two paragraphs are > contradictory: > The server may send EXPUNGE (or VANISHED) messages before the tagged > response, so the client cannot safely send more commands with message > sequence number arguments while the server is processing MOVE. The > UID MOVE command does not have this limitation. > Both MOVE and UID MOVE can be pipelined. However, pipelined MOVE and > UID MOVE commands MUST NOT specify overlapping sets of messages. > We can't have "the client cannot safely send more commands with message > sequence number arguments while the server is processing MOVE," and at > the same time allow the version of MOVE that uses sequence numbers to be > pipelined. We might also consider a citation to RFC 3501, Section 5.5 > here. Thinking about this further, since pipelined commands can be executed in any order, there is no case for which MOVE or UID MOVE can be pipelined with a command that uses sequence numbers, including MOVE. I therefore propose changing this paragraph to read something like: Both MOVE and UID MOVE can be pipelined with other commands. However, since both commands modify sequence numbers these commands MUST NOT be pipelined with additional commands (including another MOVE) that employ sequence numbers that would be affected by the MOVE or UID MOVE command. Additionally, MOVE MUST NOT be pipelined with commmands that would affect its sequence numbers. I think this covers all the cases. Thoughts? Ned From alexey.melnikov@isode.com Mon Nov 26 14:31:14 2012 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0AF4C21F862A for ; Mon, 26 Nov 2012 14:31:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.203 X-Spam-Level: X-Spam-Status: No, score=-101.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y23p3+pcMeRX for ; Mon, 26 Nov 2012 14:31:13 -0800 (PST) Received: from statler.isode.com (statler.isode.com [62.3.217.254]) by ietfa.amsl.com (Postfix) with ESMTP id 4803B21F8629 for ; Mon, 26 Nov 2012 14:31:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1353969072; d=isode.com; s=selector; i=@isode.com; bh=LW1NI3jEJregq2TWe4zzVDEvD/U3JtwblkmG3BphRS4=; 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=vl/kkRdXppXdT0SaFnWlhgIoWmDg7NOBD1F78oHbouehAzx24x7PUOdIzR93rRBYkPZKks /3vyFpnNc3HhtHp5PKVbG071t83GG7NTRt+B0KkQMc12RN6f65JMPbQBPQUMrDtMkBL1WN j4l9k0IgzHbAtCZXagwY2LlbbMb909I=; Received: from [10.217.236.8] ((unknown) [212.183.128.112]) by statler.isode.com (submission channel) via TCP with ESMTPA id ; Mon, 26 Nov 2012 22:31:11 +0000 X-SMTP-Protocol-Errors: NORDNS References: <20121123220800.12283.82353.idtracker@ietfa.amsl.com> <01ON00OXRTL600008T@mauve.mrochek.com> <9277d93e-0d2b-47cf-b522-7fa3e246ea7c@flaska.net> <50B390FF.1010005@isode.com> <01ON2SLHUUX200008T@mauve.mrochek.com> In-Reply-To: <01ON2SLHUUX200008T@mauve.mrochek.com> Message-Id: <5DAE948C-430A-407B-9003-7BF6440E9CF1@isode.com> X-Mailer: iPhone Mail (10A403) From: Alexey Melnikov Date: Mon, 26 Nov 2012 22:33:03 +0000 To: Ned Freed MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Cc: =?utf-8?Q?Jan_Kundr=C3=A1t?= , "imapext@ietf.org" Subject: Re: [imapext] Pete Resnick's Discuss on draft-ietf-imapmove-command-03: (with DISCUSS and COMMENT) X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Nov 2012 22:31:14 -0000 Hi Ned, On 26 Nov 2012, at 19:31, Ned Freed wrote: >> Hi Jan, >=20 >> On 26/11/2012 15:13, Jan Kundr=C3=A1t wrote: >> > On Saturday, 24 November 2012 20:36:45 CEST, Ned Freed wrote: >> >> Absolutely. Perhaps we need to add something like this before the thir= d >> >> paragraph in section 3.3: >> >> >> >> Although the effect of MOVE is the same as the preceeding steps, >> >> the intermediate states produced by those steps do not occur. In >> >> particular, at no time will the \DELETED flag be seen to be set. >> > >> > (Replying just to imapext, please let me know if this should've gone >> > to all recipients instead.) >> > >> > Does it mean that servers SHOULD NOT send the FLAGS \Deleted message >> > to (this, or any other parallel) IMAP session, or does it mean that >> > they MUST NOT do so? It is not clear to me from this wording. >=20 >> I don't think it actually matters. If a server mistakenly sends \Deleted >> on MOVE, it doesn't look like any harm will occur. Feel free to disagree >> with me, of course. >=20 > Cyrus described one case where it matters. Yeah, I wanted to say that there was wasted bandwidth. > Another is the Sieve interfation: > Sending out a \DELETED flag change without running the Sieve with a flag > change cause creates a silly state. >=20 > I'm strongly inclined to go with a MUST NOT here. No objection from me (speaking as a participant). From ned.freed@mrochek.com Mon Nov 26 14:40:29 2012 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D4B421F852C; Mon, 26 Nov 2012 14:40:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.569 X-Spam-Level: X-Spam-Status: No, score=-2.569 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6hZKGwrOEsNz; Mon, 26 Nov 2012 14:40:28 -0800 (PST) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id D5CB321F8503; Mon, 26 Nov 2012 14:40:28 -0800 (PST) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01ON2YX6H34G002D6J@mauve.mrochek.com>; Mon, 26 Nov 2012 14:35:26 -0800 (PST) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01ON2R5SZHSG00008T@mauve.mrochek.com>; Mon, 26 Nov 2012 14:35:23 -0800 (PST) Message-id: <01ON2YX4RUAI00008T@mauve.mrochek.com> Date: Mon, 26 Nov 2012 14:32:16 -0800 (PST) From: Ned Freed In-reply-to: "Your message dated Mon, 26 Nov 2012 13:40:52 -0800 (PST)" <01ON2XGPWZGO00008T@mauve.mrochek.com> MIME-version: 1.0 Content-type: TEXT/PLAIN References: <20121126150307.32380.97144.idtracker@ietfa.amsl.com> <01ON2XGPWZGO00008T@mauve.mrochek.com> To: Ned Freed Cc: imapmove-chairs@tools.ietf.org, draft-ietf-imapmove-command@tools.ietf.org, Barry Leiba , The IESG , imapext@ietf.org Subject: Re: [imapext] Barry Leiba's Discuss on draft-ietf-imapmove-command-03: (with DISCUSS) X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Nov 2012 22:40:29 -0000 > ... > > We can't have "the client cannot safely send more commands with message > > sequence number arguments while the server is processing MOVE," and at > > the same time allow the version of MOVE that uses sequence numbers to be > > pipelined. We might also consider a citation to RFC 3501, Section 5.5 > > here. That's a good idea and I left it out, sorry. > Thinking about this further, since pipelined commands can be executed in any > order, there is no case for which MOVE or UID MOVE can be pipelined with a > command that uses sequence numbers, including MOVE. I therefore propose > changing this paragraph to read something like: > Both MOVE and UID MOVE can be pipelined with other commands. However, > since both commands modify sequence numbers these commands MUST NOT > be pipelined with additional commands (including another MOVE) that employ > sequence numbers that would be affected by the MOVE or UID MOVE command. > Additionally, MOVE MUST NOT be pipelined with commmands that would affect > its sequence numbers. How about I add: See section 5.5 of RFC 3501 for additional restrictions on command pipelining. > I think this covers all the cases. > Thoughts? > Ned > _______________________________________________ > imapext mailing list > imapext@ietf.org > https://www.ietf.org/mailman/listinfo/imapext From barryleiba@gmail.com Mon Nov 26 14:51:30 2012 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E075221F84DB; Mon, 26 Nov 2012 14:51:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.977 X-Spam-Level: X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CbCf8xFxhvLX; Mon, 26 Nov 2012 14:51:29 -0800 (PST) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id E3F7721F84D1; Mon, 26 Nov 2012 14:51:28 -0800 (PST) Received: by mail-vc0-f172.google.com with SMTP id fw7so10755930vcb.31 for ; Mon, 26 Nov 2012 14:51:28 -0800 (PST) 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=LcdHTAj65U/DJKQbj8FR+u+5XrajeOZ2C38JVjKQI3M=; b=yuVeNGXvh4zMKKVtrFIH0biJpRMWaa8ptQuwH8eql1GKK8wGIejGpFacl5OtoB2FxN r7k7+zgxDy1XisuM+LGiJCa9vdwhJj0XG5iPB8rWOEY9s4yJrtNC/LkLYtUFmh61Uio/ eFEdeQ0AMuexn8gLGX7D6BosgNW/FChuTNchrtT8Iuo2+ezC3Kgt3N4+SJPusr1JPqq+ /Ctw7a3KQAN9Ifk4KuQ9UsMYBRZnUlfSzX2+Zt8B8WqYiI44wgB34yPZTFbKdOfcVask e8jG+udfg8eKl7kvoOOe2bEAu9oDnNzpOE9EN8a4eBL7c1HjTFd3VI4iRnVruv4mZ7NG Thow== MIME-Version: 1.0 Received: by 10.52.65.51 with SMTP id u19mr18974902vds.3.1353970288049; Mon, 26 Nov 2012 14:51:28 -0800 (PST) Sender: barryleiba@gmail.com Received: by 10.58.28.231 with HTTP; Mon, 26 Nov 2012 14:51:27 -0800 (PST) In-Reply-To: <01ON2XGPWZGO00008T@mauve.mrochek.com> References: <20121126150307.32380.97144.idtracker@ietfa.amsl.com> <01ON2XGPWZGO00008T@mauve.mrochek.com> Date: Mon, 26 Nov 2012 17:51:27 -0500 X-Google-Sender-Auth: adl-GpbwsC27fTJK5dTGmKTrAIM Message-ID: From: Barry Leiba To: Ned Freed Content-Type: text/plain; charset=ISO-8859-1 Cc: imapmove-chairs@tools.ietf.org, draft-ietf-imapmove-command@tools.ietf.org, The IESG , "imapext@ietf.org" Subject: Re: [imapext] Barry Leiba's Discuss on draft-ietf-imapmove-command-03: (with DISCUSS) X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Nov 2012 22:51:30 -0000 > Thinking about this further, since pipelined commands can be executed in any > order, there is no case for which MOVE or UID MOVE can be pipelined with a > command that uses sequence numbers, including MOVE. I therefore propose > changing this paragraph to read something like: > > Both MOVE and UID MOVE can be pipelined with other commands. However, > since both commands modify sequence numbers these commands MUST NOT > be pipelined with additional commands (including another MOVE) that employ > sequence numbers that would be affected by the MOVE or UID MOVE command. > Additionally, MOVE MUST NOT be pipelined with commmands that would affect > its sequence numbers. > > I think this covers all the cases. I'm not sure everyone reading it will understand that "MOVE 1 Banana" affects *every* sequence number in the mailbox. Also, because unrelated EXPUNGE responses can come in during a MOVE, it's not safe to pipeline MOVE after MOVE or UID MOVE, even if the message sets appear to be safe. So maybe this?: Both MOVE and UID MOVE can be pipelined with other commands, but care has to be taken. Both commands modify sequence numbers and also allow unrelated EXPUNGE responses. The renumbering of other messages in the source mailbox following any EXPUNGE response can be surprising , and makes it unsafe to pipeline any command that relies on message sequence numbers after a MOVE or UID MOVE. Similarly, MOVE cannot be pipelined after a command that might cause message renumbering. See [RFC3501], Section 5.5, for more information about sequence number ambiguities. Barry From ned.freed@mrochek.com Mon Nov 26 15:19:27 2012 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA09B21F8503; Mon, 26 Nov 2012 15:19:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.574 X-Spam-Level: X-Spam-Status: No, score=-2.574 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T5s+R2tJJ+jI; Mon, 26 Nov 2012 15:19:27 -0800 (PST) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id 3E68121F876F; Mon, 26 Nov 2012 15:19:27 -0800 (PST) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01ON30AHEIYO0027WK@mauve.mrochek.com>; Mon, 26 Nov 2012 15:14:24 -0800 (PST) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01ON30626TMO00008T@mauve.mrochek.com>; Mon, 26 Nov 2012 15:14:21 -0800 (PST) Message-id: <01ON30AFF4PM00008T@mauve.mrochek.com> Date: Mon, 26 Nov 2012 15:13:02 -0800 (PST) From: Ned Freed In-reply-to: "Your message dated Mon, 26 Nov 2012 17:51:27 -0500" MIME-version: 1.0 Content-type: TEXT/PLAIN References: <20121126150307.32380.97144.idtracker@ietfa.amsl.com> <01ON2XGPWZGO00008T@mauve.mrochek.com> To: Barry Leiba Cc: imapmove-chairs@tools.ietf.org, draft-ietf-imapmove-command@tools.ietf.org, Ned Freed , The IESG , "imapext@ietf.org" Subject: Re: [imapext] Barry Leiba's Discuss on draft-ietf-imapmove-command-03: (with DISCUSS) X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Nov 2012 23:19:28 -0000 > > Thinking about this further, since pipelined commands can be executed in any > > order, there is no case for which MOVE or UID MOVE can be pipelined with a > > command that uses sequence numbers, including MOVE. I therefore propose > > changing this paragraph to read something like: > > > > Both MOVE and UID MOVE can be pipelined with other commands. However, > > since both commands modify sequence numbers these commands MUST NOT > > be pipelined with additional commands (including another MOVE) that employ > > sequence numbers that would be affected by the MOVE or UID MOVE command. > > Additionally, MOVE MUST NOT be pipelined with commmands that would affect > > its sequence numbers. > > > > I think this covers all the cases. > I'm not sure everyone reading it will understand that "MOVE 1 Banana" > affects *every* sequence number in the mailbox. Also, because > unrelated EXPUNGE responses can come in during a MOVE, it's not safe > to pipeline MOVE after MOVE or UID MOVE, even if the message sets > appear to be safe. > So maybe this?: > Both MOVE and UID MOVE can be pipelined with other commands, but care > has to be taken. Both commands modify sequence numbers and also allow > unrelated EXPUNGE responses. The renumbering of other messages in the > source mailbox following any EXPUNGE response can be surprising , and > makes it unsafe to pipeline any command that relies on message sequence > numbers after a MOVE or UID MOVE. Similarly, MOVE cannot be pipelined > after a command that might cause message renumbering. See [RFC3501], > Section 5.5, for more information about sequence number ambiguities. Yes, this is definitely better. The only thing I think needs changing is "after a command" should be "with a command". I'm going to go ahead and put this in with that change. Ned From adrien@qbik.com Mon Nov 26 16:17:10 2012 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E262221F8531 for ; Mon, 26 Nov 2012 16:17:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.449 X-Spam-Level: X-Spam-Status: No, score=-6.449 tagged_above=-999 required=5 tests=[AWL=-4.150, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nfJiDn3BBC4O for ; Mon, 26 Nov 2012 16:17:10 -0800 (PST) Received: from smtp.qbik.com (smtp.qbik.com [210.55.214.35]) by ietfa.amsl.com (Postfix) with ESMTP id F15B821F84BB for ; Mon, 26 Nov 2012 16:17:09 -0800 (PST) Received: From [192.168.0.10] (unverified [192.168.0.10]) by SMTP Server [192.168.0.1] (WinGate SMTP Receiver v7.2.8 (Build 3469)) with SMTP id <0019374410@smtp.qbik.com>; Tue, 27 Nov 2012 13:17:44 +1300 From: "Adrien W. de Croy" To: "Ned Freed" , =?utf-8?q?Jan=20Kundr=c3=a1t?= Date: Tue, 27 Nov 2012 00:17:01 +0000 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; format=flowed; charset=utf-8 In-Reply-To: <01ON2NJO8WPE00008T@mauve.mrochek.com> Message-Id: Mime-Version: 1.0 User-Agent: eM_Client/4.0.15145.0 Cc: "imapext@ietf.org" Subject: Re: [imapext] Pete Resnick's Discuss on draft-ietf-imapmove-command-03: (with DISCUSS and COMMENT) X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: "Adrien W. de Croy" List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Nov 2012 00:17:11 -0000 =EF=BB=BF ------ Original Message ------ From: "Ned Freed" >>On Saturday, 24 November 2012 20:36:45 CEST, Ned Freed wrote:=20 >>> Absolutely. Perhaps we need to add something like this before the=20 >>third=20 >>> paragraph in section 3.3:=20 >>>=20 >>> Although the effect of MOVE is the same as the preceeding steps,=20 >>> the intermediate states produced by those steps do not occur. In=20 >>> particular, at no time will the \DELETED flag be seen to be set.=20 > >>(Replying just to imapext, please let me know if this should've gone=20 >>to all recipients instead.)=20 > >>Does it mean that servers SHOULD NOT send the FLAGS \Deleted message=20 >>to=20 >>(this, or any other parallel) IMAP session, or does it mean that they=20 >>MUST NOT=20 >>do so? It is not clear to me from this wording.=20 > =20 >I have no idea what "send" a "message" means in this context. I guess we should use language like "emit a PDU", which I take to be=20 the meaning here. Regards Adrien > The text says=20 >that the \Deleted flag must not be visibly set at any time during the=20 >operation. We can use compliance language for that to make it cleaer,=20 >but what=20 >happens inside the server is not our concern and should not be=20 >specified.=20 > Ned=20 >_______________________________________________=20 >imapext mailing list=20 >imapext@ietf.org=20 >https://www.ietf.org/mailman/listinfo/imapext=20 From ned.freed@mrochek.com Mon Nov 26 17:42:36 2012 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C307221F8531 for ; Mon, 26 Nov 2012 17:42:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.578 X-Spam-Level: X-Spam-Status: No, score=-2.578 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0z82NEci5nCr for ; Mon, 26 Nov 2012 17:42:36 -0800 (PST) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id 5147721F84B9 for ; Mon, 26 Nov 2012 17:42:36 -0800 (PST) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01ON359YYSSG002E12@mauve.mrochek.com> for imapext@ietf.org; Mon, 26 Nov 2012 17:37:32 -0800 (PST) MIME-version: 1.0 Content-type: TEXT/PLAIN; format=flowed; charset=utf-8 Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01ON30626TMO00008T@mauve.mrochek.com>; Mon, 26 Nov 2012 17:37:29 -0800 (PST) Message-id: <01ON359WZ7XA00008T@mauve.mrochek.com> Date: Mon, 26 Nov 2012 17:35:55 -0800 (PST) From: Ned Freed In-reply-to: "Your message dated Tue, 27 Nov 2012 00:17:01 +0000" References: <01ON2NJO8WPE00008T@mauve.mrochek.com> To: "Adrien W. de Croy" Cc: =?utf-8?q?Jan=20Kundr=c3=a1t?= , Ned Freed , "imapext@ietf.org" Subject: Re: [imapext] Pete Resnick's Discuss on draft-ietf-imapmove-command-03: (with DISCUSS and COMMENT) X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Nov 2012 01:42:36 -0000 >  > ------ Original Message ------ > From: "Ned Freed" > >>On Saturday, 24 November 2012 20:36:45 CEST, Ned Freed wrote: > >>> Absolutely. Perhaps we need to add something like this before the > >>third > >>> paragraph in section 3.3: > >>> > >>> Although the effect of MOVE is the same as the preceeding steps, > >>> the intermediate states produced by those steps do not occur. In > >>> particular, at no time will the \DELETED flag be seen to be set. > > > >>(Replying just to imapext, please let me know if this should've gone > >>to all recipients instead.) > > > >>Does it mean that servers SHOULD NOT send the FLAGS \Deleted message > >>to > >>(this, or any other parallel) IMAP session, or does it mean that they > >>MUST NOT > >>do so? It is not clear to me from this wording. > > > >I have no idea what "send" a "message" means in this context. > I guess we should use language like "emit a PDU", which I take to be > the meaning here. I've since realized it probably refers to responses being sent in this and other sessions. Ned From ned.freed@mrochek.com Mon Nov 26 19:16:31 2012 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD6B421F8430; Mon, 26 Nov 2012 19:16:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.582 X-Spam-Level: X-Spam-Status: No, score=-2.582 tagged_above=-999 required=5 tests=[AWL=0.017, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ra14iOuK9aJh; Mon, 26 Nov 2012 19:16:31 -0800 (PST) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id 2375221F842F; Mon, 26 Nov 2012 19:16:31 -0800 (PST) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01ON38KDXT68001QFP@mauve.mrochek.com>; Mon, 26 Nov 2012 19:11:27 -0800 (PST) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01ON3610C9JK00008T@mauve.mrochek.com>; Mon, 26 Nov 2012 19:11:24 -0800 (PST) Message-id: <01ON38KC509800008T@mauve.mrochek.com> Date: Mon, 26 Nov 2012 19:09:29 -0800 (PST) From: Ned Freed In-reply-to: "Your message dated Mon, 26 Nov 2012 10:29:08 -0600" <50B398D4.7050402@qti.qualcomm.com> MIME-version: 1.0 Content-type: TEXT/PLAIN; format=flowed References: <20121123220800.12283.82353.idtracker@ietfa.amsl.com> <01ON00OXRTL600008T@mauve.mrochek.com> <50B398D4.7050402@qti.qualcomm.com> To: Pete Resnick Cc: Ned Freed , imapmove-chairs@tools.ietf.org, draft-ietf-imapmove-command@tools.ietf.org, The IESG , "imapext@ietf.org" , Barry Leiba Subject: Re: [imapext] Pete Resnick's Discuss on draft-ietf-imapmove-command-03: (with DISCUSS and COMMENT) X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Nov 2012 03:16:31 -0000 > If you're going this route, maybe even a bit more would be useful: > Although the effect of the MOVE is the same as the preceding steps, > the semantics are not identical: The intermediate states produced by > those steps do not occur, and the response codes are different. In > particular, though the COPY and EXPUNGE response codes will return, > no response code for a STORE will be generated nor will the \DELETED > flag be set for any message. I've opted for a variant of this that uses MUST NOT compliance language. > >> 2. We did discuss, though only very briefly, whether to have a > >> separate imapsieve cause for this, and decided that it wasn't worth > >> the complexity. No one has a use case for needing it. If you do, > >> we'd like to hear it.. > >> > > Specifically, I brought up the idea of a "MOVE" cause. Nobody seemed interested > > in it. > And it's tricky: I mentioned an EXPUNGE cause above, but that would have > to trigger before the message was actually gone from the original > mailbox (because otherwise you wouldn't have access to the message that > just got expunged). A MOVE clause is a little better since you would > have access to the destination message. But if nobody is interested, so > be it. That seems to be the case. As I've commented before, we may have to revisit various things about Sieve in IMAP if it sees significant deployment. Ned From internet-drafts@ietf.org Mon Nov 26 20:17:56 2012 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 759AD21F846A; Mon, 26 Nov 2012 20:17:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.473 X-Spam-Level: X-Spam-Status: No, score=-102.473 tagged_above=-999 required=5 tests=[AWL=0.126, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iijv+jOkTIdu; Mon, 26 Nov 2012 20:17:56 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3F4D21F851B; Mon, 26 Nov 2012 20:17:55 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.36 Message-ID: <20121127041755.2759.9805.idtracker@ietfa.amsl.com> Date: Mon, 26 Nov 2012 20:17:55 -0800 Cc: imapext@ietf.org Subject: [imapext] I-D Action: draft-ietf-imapmove-command-04.txt X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Nov 2012 04:17:56 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the IMAP MOVE extension Working Group of the = IETF. Title : Internet Message Access Protocol (IMAP) - MOVE Extension Author(s) : Arnt Gulbrandsen Ned Freed Filename : draft-ietf-imapmove-command-04.txt Pages : 10 Date : 2012-11-26 Abstract: This document defines an IMAP extension consisting of two new commands, MOVE and UID MOVE, that are used to move messages from one mailbox to another. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-imapmove-command There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-imapmove-command-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-imapmove-command-04 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From arnt@gulbrandsen.priv.no Mon Nov 26 22:41:08 2012 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B77421F8443; Mon, 26 Nov 2012 22:41:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H8Ub15M9Xg00; Mon, 26 Nov 2012 22:41:08 -0800 (PST) Received: from strange.aox.org (strange.aox.org [IPv6:2001:4d88:100c::1]) by ietfa.amsl.com (Postfix) with ESMTP id 00D2721F843F; Mon, 26 Nov 2012 22:41:07 -0800 (PST) Received: from fri.gulbrandsen.priv.no (localhost [127.0.0.1]) by strange.aox.org (Postfix) with ESMTP id 0A703FA0090; Tue, 27 Nov 2012 06:41:06 +0000 (UTC) Received: from arnt@gulbrandsen.priv.no by fri.gulbrandsen.priv.no (Archiveopteryx 3.1.4) with esmtpsa id 1353998465-9485-9484/11/1; Tue, 27 Nov 2012 06:41:05 +0000 Message-Id: <50B45F86.20008@gulbrandsen.priv.no> Date: Tue, 27 Nov 2012 07:36:54 +0100 From: Arnt Gulbrandsen User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121028 Thunderbird/16.0.2 Mime-Version: 1.0 To: Ned Freed References: <20121126150307.32380.97144.idtracker@ietfa.amsl.com> <01ON2XGPWZGO00008T@mauve.mrochek.com> In-Reply-To: <01ON2XGPWZGO00008T@mauve.mrochek.com> Content-Type: text/plain; charset=iso-8859-1; format=flowed Cc: imapmove-chairs@tools.ietf.org, draft-ietf-imapmove-command@tools.ietf.org, Barry Leiba , The IESG , imapext@ietf.org Subject: Re: [imapext] Barry Leiba's Discuss on draft-ietf-imapmove-command-03: (with DISCUSS) X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Nov 2012 06:41:08 -0000 On 11/26/2012 10:40 PM, Ned Freed wrote: > Thoughts? Fine Arnt From alexey.melnikov@isode.com Wed Nov 28 09:03:39 2012 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 114B721F88DF for ; Wed, 28 Nov 2012 09:03:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.518 X-Spam-Level: X-Spam-Status: No, score=-102.518 tagged_above=-999 required=5 tests=[AWL=0.081, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kSpsUuwX8fe3 for ; Wed, 28 Nov 2012 09:03:38 -0800 (PST) Received: from statler.isode.com (statler.isode.com [62.3.217.254]) by ietfa.amsl.com (Postfix) with ESMTP id 520E421F88DE for ; Wed, 28 Nov 2012 09:03:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1354122217; d=isode.com; s=selector; i=@isode.com; bh=CN+nvWXyuaxSuaYZl6GyZEH4TvBIktWi8aikqj+SgTc=; 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=M27VCp5uIXBzNlluelf+yy0Ioj5O5wfl98hr7zaw6o1JmiVFSEhtZsha5eoyPcMpaK/4BJ FIGzGjKXZrk71NsvKK7QgYXnW8TEoggcgUdS8dbDSzveUZFhlO0nyP1QXvfMZQ2F+iQpCj S7WLerSKBsSNOtbXyiH9lmEpDNLsDH8=; Received: from [172.16.1.29] (shiny.isode.com [62.3.217.250]) by statler.isode.com (submission channel) via TCP with ESMTPA id ; Wed, 28 Nov 2012 17:03:37 +0000 Message-ID: <50B64429.2030804@isode.com> Date: Wed, 28 Nov 2012 17:04:41 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 To: "imapext@ietf.org" MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [imapext] Additional text about interaction between MOVE and QRESYNC X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Nov 2012 17:03:39 -0000 I've decided to implement MOVE in Isode's server and I think something like the following should be added to section 4.4. While this can be deducted from the fact that MOVE is sort of COPY+STORE+EXPUNGE, RFC 5162 explicitly lists all commands affected by it. So I propose adding: If the server is capable of storing modification sequences for the selected mailbox, it MUST increment the per-mailbox mod-sequence if at least one message was permanently moved due to the execution of the MOVE/UID MOVE command. For each permanently removed message, the server MUST remember the incremented mod-sequence and corresponding UID. If at least one message got moved, the server MUST send the updated per-mailbox modification sequence using the HIGHESTMODSEQ response code (defined in [RFC4551]) in the tagged OK response. When a message is moved to a target mailbox, if the server is capable of storing modification sequences for the mailbox, the server MUST generate a new modification sequence that is higher than the highest modification sequence of all messages in the mailbox and assigns it to the moved message. And add RFC 4551 to references (Informative is Ok, but Normative would do as well). I think this also makes RFC 5162 Normative. From ned.freed@mrochek.com Wed Nov 28 09:37:04 2012 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A9E621F861D for ; Wed, 28 Nov 2012 09:37:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.587 X-Spam-Level: X-Spam-Status: No, score=-2.587 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KetEDFOoxE1g for ; Wed, 28 Nov 2012 09:37:03 -0800 (PST) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id BD0E621F85FE for ; Wed, 28 Nov 2012 09:37:03 -0800 (PST) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01ON5GWP9NHS0029FN@mauve.mrochek.com> for imapext@ietf.org; Wed, 28 Nov 2012 09:32:01 -0800 (PST) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01ON3610C9JK00008T@mauve.mrochek.com>; Wed, 28 Nov 2012 09:31:59 -0800 (PST) Message-id: <01ON5GWNXHKK00008T@mauve.mrochek.com> Date: Wed, 28 Nov 2012 09:26:28 -0800 (PST) From: Ned Freed In-reply-to: "Your message dated Wed, 28 Nov 2012 17:04:41 +0000" <50B64429.2030804@isode.com> MIME-version: 1.0 Content-type: TEXT/PLAIN; Format=flowed References: <50B64429.2030804@isode.com> To: Alexey Melnikov Cc: "imapext@ietf.org" Subject: Re: [imapext] Additional text about interaction between MOVE and QRESYNC X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Nov 2012 17:37:04 -0000 > I've decided to implement MOVE in Isode's server and I think something > like the following should be added to section 4.4. While this can be > deducted from the fact that MOVE is sort of COPY+STORE+EXPUNGE, RFC 5162 > explicitly lists all commands affected by it. So I propose adding: > If the server is capable of storing modification sequences for the > selected mailbox, it MUST increment the per-mailbox mod-sequence if > at least one message was permanently moved due to the execution of > the MOVE/UID MOVE command. For each permanently removed message, > the server MUST remember the incremented mod-sequence and corresponding > UID. If at least one message got moved, the server MUST send the > updated per-mailbox modification sequence using the HIGHESTMODSEQ > response code (defined in [RFC4551]) in the tagged OK response. > When a message is moved to a target mailbox, if the server is capable > of storing modification sequences for the mailbox, the server MUST > generate a new modification sequence that is higher than the highest > modification sequence of all messages in the mailbox and assigns it > to the moved message. This addition is being proposed pretty late in the game. OTOH, it's not actually changing anything, only stating some requirements explicitly rather than leaving them to implementors to work out. I'm therefore inclined to add this text, modulo a couple of editorial tweaks. Comments ASAP please. > And add RFC 4551 to references (Informative is Ok, but Normative would > do as well). It's being used as a source of a definition used in a requirement. I think that makes it normative. > I think this also makes RFC 5162 Normative. That's actually a little less clear to me, but I'm inclined to go along with it. Ned From barryleiba.mailing.lists@gmail.com Wed Nov 28 09:42:21 2012 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7322321F85DD for ; Wed, 28 Nov 2012 09:42:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.788 X-Spam-Level: X-Spam-Status: No, score=-102.788 tagged_above=-999 required=5 tests=[AWL=0.189, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zmr3KRg445bD for ; Wed, 28 Nov 2012 09:42:20 -0800 (PST) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 89A3421F85B4 for ; Wed, 28 Nov 2012 09:42:20 -0800 (PST) Received: by mail-ee0-f44.google.com with SMTP id b47so8617192eek.31 for ; Wed, 28 Nov 2012 09:42:19 -0800 (PST) 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=Kjwy6i0DXaKSgQaMcdWKZsw8onDqw6GlJ3hbekta4XY=; b=Y0sh5lP/EHrFFheC8naA1UcjFlseOmS1xzmUGVpBi/CLpc72QPMEe2idO2XZtWEJaG hbMf4xA/+0DtLn1t8KI5RBvY+S2aYD3U9Lb56ne7nqKjHwsXUgH1pTOH22cMBAYyIOKf Lg/hygyDFo1DIY0hfrsjoSxoHbr43eXJnw0sf59G3UT40v7HK/9mv0vBVhdZXsSIRS5R 4n6TUr29HiOh78tzjTM+7DNqJmrmmfWLHKC7izKyLBzfP6/CyD5YN+fqhVNeswnaY/uZ yEOLkyQ/o+9wrkyJ5BNOz9JrUxg1i4HXvL+FPiHOknHjieyrDqieeHL1ETRB/7An3oU7 tSsg== MIME-Version: 1.0 Received: by 10.14.218.69 with SMTP id j45mr71632157eep.35.1354124539734; Wed, 28 Nov 2012 09:42:19 -0800 (PST) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.14.100.202 with HTTP; Wed, 28 Nov 2012 09:42:19 -0800 (PST) In-Reply-To: <01ON5GWNXHKK00008T@mauve.mrochek.com> References: <50B64429.2030804@isode.com> <01ON5GWNXHKK00008T@mauve.mrochek.com> Date: Wed, 28 Nov 2012 12:42:19 -0500 X-Google-Sender-Auth: 5MQMuCqatoCA1xMqqiA4KTbdReA Message-ID: From: Barry Leiba To: Ned Freed Content-Type: text/plain; charset=ISO-8859-1 Cc: Alexey Melnikov , "imapext@ietf.org" Subject: Re: [imapext] Additional text about interaction between MOVE and QRESYNC X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Nov 2012 17:42:21 -0000 > This addition is being proposed pretty late in the game. OTOH, it's not > actually changing anything, only stating some requirements explicitly rather > than leaving them to implementors to work out. ... > Comments ASAP please. Same analysis as yours. Given that this comes directly from implementation experience, I think it's valuable to add it. Given that it's a clarification, not any protocol change, I think it's OK to add it now without going back through any process. Barry, as participant From ned.freed@mrochek.com Wed Nov 28 10:06:27 2012 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A22421F8661 for ; Wed, 28 Nov 2012 10:06:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.588 X-Spam-Level: X-Spam-Status: No, score=-2.588 tagged_above=-999 required=5 tests=[AWL=0.011, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5dGBcoddN6NT for ; Wed, 28 Nov 2012 10:06:26 -0800 (PST) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id A45D621F841C for ; Wed, 28 Nov 2012 10:06:26 -0800 (PST) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01ON5HX4UD9S001F2Q@mauve.mrochek.com> for imapext@ietf.org; Wed, 28 Nov 2012 10:01:23 -0800 (PST) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01ON3610C9JK00008T@mauve.mrochek.com> for imapext@ietf.org; Wed, 28 Nov 2012 10:01:22 -0800 (PST) Message-id: <01ON5HX3L6QM00008T@mauve.mrochek.com> Date: Wed, 28 Nov 2012 09:49:06 -0800 (PST) From: Ned Freed MIME-version: 1.0 Content-type: multipart/mixed; boundary="Boundary_(ID_CF4g0wQAS0mFthfsbGXSPQ)" To: "imapext@ietf.org" Subject: [imapext] Improved introduction to imapmove-command? X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Nov 2012 18:06:27 -0000 --Boundary_(ID_CF4g0wQAS0mFthfsbGXSPQ) Content-type: TEXT/PLAIN Benoit Claise entered a comment (attached below) saying that the current introduction is a little thin (which it is) and suggesting the addition of some text from the charter. The current introduction text is very short: This document defines an IMAP [RFC3501] extension to facilitate moving messages from one mailbox to another. This is accomplished by defining a new MOVE command and extending the UID command to allow UID MOVE. A move function is not provided in the base IMAP specification, so clients have instead had to use a combination of the COPY, STORE, and EXPUNGE commands to perform this very common operation. This has meant needing to cope with partial failures and side effects that can occur when multiple commands are involved. The MOVE extension is present in any IMAP4 implementation which returns "MOVE" as one of the supported capabilities to the CAPABILITY command. My view is that the first and last paragraphs are fine, but the middle one could do with some elaboration. I wish using the charter text had occurred to me earlier; if it had I would have already done it. Anyway, how about the following as a replacement? A move function is not provided in the base IMAP specification, so clients have instead had to use a combination of the COPY, STORE, and EXPUNGE commands to perform this very common operation. 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 can have the side effect of expunging 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/STORE/EXPUNGE process. I'm pretty sure this changes nothing about the protocol, so it's a safe change to make at this point. Thoughts? --Boundary_(ID_CF4g0wQAS0mFthfsbGXSPQ) Content-type: message/rfc822 Return-path: Received: from grenache.tools.ietf.org (unknown [77.72.230.30]) by mauve.mrochek.com (PMDF V6.1-1 #35243) with ESMTP id <01ON3ML9XJS40026XT@mauve.mrochek.com> for ned@mauve.mrochek.com; Tue, 27 Nov 2012 01:53:20 -0800 (PST) Received: from mail.ietf.org ([2001:1890:126c::1:1e]:34424) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1TdHq6-0005Md-HE; Tue, 27 Nov 2012 10:52:27 +0100 Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF1B821F8530; Tue, 27 Nov 2012 01:52:14 -0800 (PST) Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZXLgpF96H6sv; Tue, 27 Nov 2012 01:52:14 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7631821F8507; Tue, 27 Nov 2012 01:52:14 -0800 (PST) Date: Tue, 27 Nov 2012 01:52:14 -0800 From: Benoit Claise Subject: Benoit Claise's No Objection on draft-ietf-imapmove-command-04: (with COMMENT) Resent-to: arnt@gulbrandsen.priv.no, ned+ietf@mrochek.com Resent-to: alexey.melnikov@isode.com, ned.freed@mrochek.com To: The IESG Cc: imapmove-chairs@tools.ietf.org, draft-ietf-imapmove-command@tools.ietf.org Resent-message-id: <01ON3MLDZL3S0026XT@mauve.mrochek.com> Message-id: <20121127095214.22651.42835.idtracker@ietfa.amsl.com> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII X-Virus-Scanned: amavisd-new at amsl.com X-Test-IDTracker: no X-IETF-IDTracker: 4.36 X-SA-Exim-Connect-IP: 2001:1890:126c::1:1e X-SA-Exim-Rcpt-To: draft-ietf-imapmove-command@tools.ietf.org, imapmove-chairs@tools.ietf.org X-SA-Exim-Mail-From: bclaise@cisco.com X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on grenache.tools.ietf.org X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on grenache.tools.ietf.org) List-Id: Original-recipient: rfc822;ned.freed@mrochek.com Spam-test: False ; 1.3 / 4.5 ; RDNS_NONE X-Spam-Status: No, score=-1.9 required=3.0 tests=BAYES_00 autolearn=no version=3.3.2 X-Spam-Level: Benoit Claise has entered the following ballot position for draft-ietf-imapmove-command-04: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- No objection to the publication of the document, but one observation: I believe that the intro is a little bit light, while I found some good text from the charter could be cut/pasted: 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 can have the side effect of expunging 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. We sometimes make too hard to read RFCs by only focusing on the protocol specifications, and neglecting the problem statement and use case. --Boundary_(ID_CF4g0wQAS0mFthfsbGXSPQ)-- From alexey.melnikov@isode.com Wed Nov 28 10:10:48 2012 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AAF3321F8468 for ; Wed, 28 Nov 2012 10:10:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.527 X-Spam-Level: X-Spam-Status: No, score=-102.527 tagged_above=-999 required=5 tests=[AWL=0.072, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hbapl++N8g9i for ; Wed, 28 Nov 2012 10:10:46 -0800 (PST) Received: from statler.isode.com (statler.isode.com [62.3.217.254]) by ietfa.amsl.com (Postfix) with ESMTP id 1EE1C21F844E for ; Wed, 28 Nov 2012 10:10:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1354126245; d=isode.com; s=selector; i=@isode.com; bh=kno5vZ/CavRGldsOZZ2mcRrox8CGumepRrvRl8UHhT8=; 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=IQhd174Qa96epfThOvWUlUCmylBUsCWUv+S5QHItZvf66HaZEiC6hBrFq2jJUxpdTGaINe pPnI7EnW/my5VUrd6JtGjRxPuDRhCNP0xTeDS4tNK/S6vw5Vlr7mTfR0tOVjQ/uCg4KOOV Kx3t65B4SWHz8ReitUyor+NteKrJc3Y=; Received: from [172.16.1.29] (shiny.isode.com [62.3.217.250]) by statler.isode.com (submission channel) via TCP with ESMTPA id ; Wed, 28 Nov 2012 18:10:45 +0000 Message-ID: <50B653E3.2040200@isode.com> Date: Wed, 28 Nov 2012 18:11:47 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 To: imapext@ietf.org References: <01ON5HX3L6QM00008T@mauve.mrochek.com> In-Reply-To: <01ON5HX3L6QM00008T@mauve.mrochek.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [imapext] Improved introduction to imapmove-command? X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Nov 2012 18:10:48 -0000 On 28/11/2012 17:49, Ned Freed wrote: > Benoit Claise entered a comment (attached below) saying that the current > introduction is a little thin (which it is) and suggesting the addition > of some text from the charter. > > The current introduction text is very short: > > This document defines an IMAP [RFC3501] extension to facilitate > moving messages from one mailbox to another. This is accomplished by > defining a new MOVE command and extending the UID command to allow > UID MOVE. > > A move function is not provided in the base IMAP specification, so > clients have instead had to use a combination of the COPY, STORE, and > EXPUNGE commands to perform this very common operation. This has > meant needing to cope with partial failures and side effects that can > occur when multiple commands are involved. > > The MOVE extension is present in any IMAP4 implementation which > returns "MOVE" as one of the supported capabilities to the CAPABILITY > command. > > My view is that the first and last paragraphs are fine, but the middle one > could do with some elaboration. I wish using the charter text had occurred to > me earlier; if it had I would have already done it. > > Anyway, how about the following as a replacement? > > A move function is not provided in the base IMAP specification, so > clients have instead had to use a combination of the COPY, STORE, and > EXPUNGE commands to perform this very common operation. > > 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 can have the side effect of > expunging 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/STORE/EXPUNGE > process. > > I'm pretty sure this changes nothing about the protocol, so it's a safe > change to make at this point. > > Thoughts? Works for me (speaking as a participant). From tss@iki.fi Wed Nov 28 12:43:38 2012 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CE9621F8421 for ; Wed, 28 Nov 2012 12:43:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BkstdJDVAkjx for ; Wed, 28 Nov 2012 12:43:37 -0800 (PST) Received: from dovecot.org (dovecot.org [193.210.130.67]) by ietfa.amsl.com (Postfix) with ESMTP id 2206021F8319 for ; Wed, 28 Nov 2012 12:43:35 -0800 (PST) Received: from [192.168.10.101] (a88-112-255-76.elisa-laajakaista.fi [88.112.255.76]) by dovecot.org (Postfix) with ESMTP id DB3961AE881A; Wed, 28 Nov 2012 22:43:33 +0200 (EET) Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Timo Sirainen In-Reply-To: <50B64429.2030804@isode.com> Date: Wed, 28 Nov 2012 22:43:34 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <50B64429.2030804@isode.com> To: Alexey Melnikov X-Mailer: Apple Mail (2.1085) Cc: "imapext@ietf.org" Subject: Re: [imapext] Additional text about interaction between MOVE and QRESYNC X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Nov 2012 20:43:38 -0000 On 28.11.2012, at 19.04, Alexey Melnikov wrote: > I've decided to implement MOVE in Isode's server and I think something = like the following should be added to section 4.4. While this can be = deducted from the fact that MOVE is sort of COPY+STORE+EXPUNGE, RFC 5162 = explicitly lists all commands affected by it. So I propose adding: >=20 > If the server is capable of storing modification sequences for the > selected mailbox, it MUST increment the per-mailbox mod-sequence if > at least one message was permanently moved due to the execution of > the MOVE/UID MOVE command. For each permanently removed message, > the server MUST remember the incremented mod-sequence and = corresponding > UID. If at least one message got moved, the server MUST send the > updated per-mailbox modification sequence using the HIGHESTMODSEQ > response code (defined in [RFC4551]) in the tagged OK response. Hmm. I'm not sure if it MUST be sent in the tagged OK response. Untagged = OK response would work as well. In some cases the resp-text in tagged OK = might be something else (like in a partial failure). From ned.freed@mrochek.com Wed Nov 28 14:22:48 2012 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCB7021F8943 for ; Wed, 28 Nov 2012 14:22:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.591 X-Spam-Level: X-Spam-Status: No, score=-2.591 tagged_above=-999 required=5 tests=[AWL=0.008, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z-2TLwVthdNj for ; Wed, 28 Nov 2012 14:22:48 -0800 (PST) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id 614E821F893B for ; Wed, 28 Nov 2012 14:22:48 -0800 (PST) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01ON5QVYXFY8002BX0@mauve.mrochek.com> for imapext@ietf.org; Wed, 28 Nov 2012 14:17:46 -0800 (PST) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01ON3610C9JK00008T@mauve.mrochek.com>; Wed, 28 Nov 2012 14:17:44 -0800 (PST) Message-id: <01ON5QVXJYO600008T@mauve.mrochek.com> Date: Wed, 28 Nov 2012 14:14:57 -0800 (PST) From: Ned Freed In-reply-to: "Your message dated Wed, 28 Nov 2012 22:43:34 +0200" MIME-version: 1.0 Content-type: TEXT/PLAIN References: <50B64429.2030804@isode.com> To: Timo Sirainen Cc: Alexey Melnikov , "imapext@ietf.org" Subject: Re: [imapext] Additional text about interaction between MOVE and QRESYNC X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Nov 2012 22:22:49 -0000 > On 28.11.2012, at 19.04, Alexey Melnikov wrote: > > I've decided to implement MOVE in Isode's server and I think something like the following should be added to section 4.4. While this can be deducted from the fact that MOVE is sort of COPY+STORE+EXPUNGE, RFC 5162 explicitly lists all commands affected by it. So I propose adding: > > > > If the server is capable of storing modification sequences for the > > selected mailbox, it MUST increment the per-mailbox mod-sequence if > > at least one message was permanently moved due to the execution of > > the MOVE/UID MOVE command. For each permanently removed message, > > the server MUST remember the incremented mod-sequence and corresponding > > UID. If at least one message got moved, the server MUST send the > > updated per-mailbox modification sequence using the HIGHESTMODSEQ > > response code (defined in [RFC4551]) in the tagged OK response. > Hmm. I'm not sure if it MUST be sent in the tagged OK response. Untagged OK > response would work as well. In some cases the resp-text in tagged OK might be > something else (like in a partial failure). RFC 4551 section 3.1.1 specifically says "OK untagged response". So I think this is simply wrong. Shall I drop "tagged" or change it to "untagged"? Ned From tss@iki.fi Wed Nov 28 14:32:48 2012 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9807621F8914 for ; Wed, 28 Nov 2012 14:32:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vnBNaKGOMx1D for ; Wed, 28 Nov 2012 14:32:48 -0800 (PST) Received: from dovecot.org (dovecot.org [193.210.130.67]) by ietfa.amsl.com (Postfix) with ESMTP id 0010C21F8910 for ; Wed, 28 Nov 2012 14:32:47 -0800 (PST) Received: from [192.168.10.101] (a88-112-255-76.elisa-laajakaista.fi [88.112.255.76]) by dovecot.org (Postfix) with ESMTP id 5A2271AE87E0; Thu, 29 Nov 2012 00:32:46 +0200 (EET) Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Timo Sirainen In-Reply-To: <01ON5QVXJYO600008T@mauve.mrochek.com> Date: Thu, 29 Nov 2012 00:32:46 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <50B64429.2030804@isode.com> <01ON5QVXJYO600008T@mauve.mrochek.com> To: Ned Freed X-Mailer: Apple Mail (2.1085) Cc: Alexey Melnikov , "imapext@ietf.org" Subject: Re: [imapext] Additional text about interaction between MOVE and QRESYNC X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Nov 2012 22:32:48 -0000 On 29.11.2012, at 0.14, Ned Freed wrote: >> On 28.11.2012, at 19.04, Alexey Melnikov wrote: >=20 >>> I've decided to implement MOVE in Isode's server and I think = something like the following should be added to section 4.4. While this = can be deducted from the fact that MOVE is sort of COPY+STORE+EXPUNGE, = RFC 5162 explicitly lists all commands affected by it. So I propose = adding: >>>=20 >>> If the server is capable of storing modification sequences for the >>> selected mailbox, it MUST increment the per-mailbox mod-sequence if >>> at least one message was permanently moved due to the execution of >>> the MOVE/UID MOVE command. For each permanently removed message, >>> the server MUST remember the incremented mod-sequence and = corresponding >>> UID. If at least one message got moved, the server MUST send the >>> updated per-mailbox modification sequence using the HIGHESTMODSEQ >>> response code (defined in [RFC4551]) in the tagged OK response. >=20 >> Hmm. I'm not sure if it MUST be sent in the tagged OK response. = Untagged OK >> response would work as well. In some cases the resp-text in tagged OK = might be >> something else (like in a partial failure). >=20 > RFC 4551 section 3.1.1 specifically says "OK untagged response". So I = think > this is simply wrong. It talks about it as a reply to SELECT/EXAMINE commands. RFC 5162 talks = about it being used in tagged replies to other commands. So returning = HIGHESTMODSEQ in the tagged reply is the common case, but I think it's = just as valid to send it as untagged just before the tagged reply. > Shall I drop "tagged" or change it to "untagged"? I'm not sure what's the cleanest way to say it. That or "tagged or = untagged". From ned.freed@mrochek.com Wed Nov 28 14:44:20 2012 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5543021F895D for ; Wed, 28 Nov 2012 14:44:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.591 X-Spam-Level: X-Spam-Status: No, score=-2.591 tagged_above=-999 required=5 tests=[AWL=0.008, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o8LMVVe3dVPI for ; Wed, 28 Nov 2012 14:44:20 -0800 (PST) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id E4A0421F8933 for ; Wed, 28 Nov 2012 14:44:19 -0800 (PST) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01ON5RMNRLV4002HOM@mauve.mrochek.com> for imapext@ietf.org; Wed, 28 Nov 2012 14:39:17 -0800 (PST) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01ON3610C9JK00008T@mauve.mrochek.com>; Wed, 28 Nov 2012 14:39:14 -0800 (PST) Message-id: <01ON5RMLUXA200008T@mauve.mrochek.com> Date: Wed, 28 Nov 2012 14:38:29 -0800 (PST) From: Ned Freed In-reply-to: "Your message dated Thu, 29 Nov 2012 00:32:46 +0200" MIME-version: 1.0 Content-type: TEXT/PLAIN References: <50B64429.2030804@isode.com> <01ON5QVXJYO600008T@mauve.mrochek.com> To: Timo Sirainen Cc: Alexey Melnikov , Ned Freed , "imapext@ietf.org" Subject: Re: [imapext] Additional text about interaction between MOVE and QRESYNC X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Nov 2012 22:44:20 -0000 > It talks about it as a reply to SELECT/EXAMINE commands. RFC 5162 talks about it being used in tagged replies to other commands. So returning HIGHESTMODSEQ in the tagged reply is the common case, but I think it's just as valid to send it as untagged just before the tagged reply. OK. > > Shall I drop "tagged" or change it to "untagged"? > I'm not sure what's the cleanest way to say it. That or "tagged or untagged". "tagged or untagged OK response" is what I have now. Ned From alexey.melnikov@isode.com Thu Nov 29 02:46:25 2012 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFE7421F88E9 for ; Thu, 29 Nov 2012 02:46:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.203 X-Spam-Level: X-Spam-Status: No, score=-101.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eFuY1JE358G9 for ; Thu, 29 Nov 2012 02:46:25 -0800 (PST) Received: from statler.isode.com (statler.isode.com [62.3.217.254]) by ietfa.amsl.com (Postfix) with ESMTP id F307121F88E0 for ; Thu, 29 Nov 2012 02:46:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1354185983; d=isode.com; s=selector; i=@isode.com; bh=Bo7ucKZercoDBqJEH0Uz/HmKQwMLM1uQHc2Q1pMcl5Y=; 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=dwm2S2oMpc4UKuxZuY7nFpQz+yjDepugf7FCRiyCnkHXKvJxK/CTVcaM1Mbnp2sRlJqWnF JMPtaHkQqe2UmUKOZlf+cJUiPqWaBo/keZri9GgrIoit5kG+QA09sxb0UsBs6wDXwu5sd3 BgLz4ScsY3VHEBO78eY8MEMtqtbe8+w=; Received: from [10.217.236.8] ((unknown) [212.183.128.98]) by statler.isode.com (submission channel) via TCP with ESMTPA id ; Thu, 29 Nov 2012 10:46:23 +0000 X-SMTP-Protocol-Errors: NORDNS References: <50B64429.2030804@isode.com> <01ON5QVXJYO600008T@mauve.mrochek.com> <01ON5RMLUXA200008T@mauve.mrochek.com> In-Reply-To: <01ON5RMLUXA200008T@mauve.mrochek.com> Message-Id: X-Mailer: iPhone Mail (10A403) From: Alexey Melnikov Date: Thu, 29 Nov 2012 10:47:10 +0000 To: Ned Freed MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Cc: Timo Sirainen , "imapext@ietf.org" Subject: Re: [imapext] Additional text about interaction between MOVE and QRESYNC X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Nov 2012 10:46:25 -0000 On 28 Nov 2012, at 22:38, Ned Freed wrote: >> It talks about it as a reply to SELECT/EXAMINE commands. RFC 5162 talks a= bout it being used in tagged replies to other commands. So returning HIGHEST= MODSEQ in the tagged reply is the common case, but I think it's just as vali= d to send it as untagged just before the tagged reply. >=20 > OK. Agreed. >>> Shall I drop "tagged" or change it to "untagged"? >=20 >> I'm not sure what's the cleanest way to say it. That or "tagged or untagg= ed". >=20 > "tagged or untagged OK response" is what I have now. Works for me. From internet-drafts@ietf.org Thu Nov 29 08:26:39 2012 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7386A21F8616; Thu, 29 Nov 2012 08:26:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.525 X-Spam-Level: X-Spam-Status: No, score=-102.525 tagged_above=-999 required=5 tests=[AWL=0.074, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lOeLmJLlI36d; Thu, 29 Nov 2012 08:26:38 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 310C321F875A; Thu, 29 Nov 2012 08:26:38 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.36 Message-ID: <20121129162637.28724.48381.idtracker@ietfa.amsl.com> Date: Thu, 29 Nov 2012 08:26:37 -0800 Cc: imapext@ietf.org Subject: [imapext] I-D Action: draft-ietf-imapmove-command-05.txt X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Nov 2012 16:26:39 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the IMAP MOVE extension Working Group of the = IETF. Title : Internet Message Access Protocol (IMAP) - MOVE Extension Author(s) : Arnt Gulbrandsen Ned Freed Filename : draft-ietf-imapmove-command-05.txt Pages : 11 Date : 2012-11-29 Abstract: This document defines an IMAP extension consisting of two new commands, MOVE and UID MOVE, that are used to move messages from one mailbox to another. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-imapmove-command There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-imapmove-command-05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-imapmove-command-05 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From barryleiba@gmail.com Thu Nov 29 09:08:41 2012 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EFA621F8B22 for ; Thu, 29 Nov 2012 09:08:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.977 X-Spam-Level: X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M7Ma8QIClQ2y for ; Thu, 29 Nov 2012 09:08:40 -0800 (PST) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8C46B21F8B15 for ; Thu, 29 Nov 2012 09:08:40 -0800 (PST) Received: by mail-vc0-f172.google.com with SMTP id fw7so14413674vcb.31 for ; Thu, 29 Nov 2012 09:08:40 -0800 (PST) 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=rLGaXZpRTNFiJoK3gdiqy5Uxy6GHX1c2JT13dcZQX80=; b=L2nBMpIZ9PX+4xMXgtxN/X0Ere3CL8Y+AlOIGmpRRZp4qXfYTNnr6JVXNJ0qkT4vuy vXORyg9eVF8+6nxBMJZiy4JUjN0FoMQNtFvZdo2syL6rflYoa+zw5wKFGtpn6n6s96Eh oIeBeFyKT/4PsvxZ1v/chV+HAJdnsjMgwws2NH+V7Vqk7cFvLIeYwrbN1WTnPU88OqVl Dwx7iqTLaAqVQG/D6vzLdTMMckTO/ZQOMA/PKKKxx+tbesC0K1I3v0m8MO5cGCqR5+CU 5PjPh2bP4Iw2eQzROcK+++2W4IUTBEYm5tsB+O8r+tTJS6umM92beipnsa/WFYUyWkVZ ZzGg== MIME-Version: 1.0 Received: by 10.52.26.176 with SMTP id m16mr28281652vdg.64.1354208919960; Thu, 29 Nov 2012 09:08:39 -0800 (PST) Sender: barryleiba@gmail.com Received: by 10.58.28.231 with HTTP; Thu, 29 Nov 2012 09:08:39 -0800 (PST) In-Reply-To: <20121129162638.28724.79200.idtracker@ietfa.amsl.com> References: <20121129162638.28724.79200.idtracker@ietfa.amsl.com> Date: Thu, 29 Nov 2012 12:08:39 -0500 X-Google-Sender-Auth: -7xuLAPr-dlDqeelP0wa95R6I3M Message-ID: From: Barry Leiba To: "imapext@ietf.org" Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [imapext] New Version Notification - draft-ietf-imapmove-command-05.txt X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Nov 2012 17:08:41 -0000 > A new version (-05) has been submitted for draft-ietf-imapmove-command: > http://www.ietf.org/internet-drafts/draft-ietf-imapmove-command-05.txt This version was just approved on the IESG telechat. You should see the formal announcement early next week. Now we just need to record implementation experience to finish the chartered work! Barry From tss@iki.fi Thu Nov 29 13:04:37 2012 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DFA421F8C5B for ; Thu, 29 Nov 2012 13:04:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yFyQSW9UMrzH for ; Thu, 29 Nov 2012 13:04:37 -0800 (PST) Received: from dovecot.org (dovecot.org [193.210.130.67]) by ietfa.amsl.com (Postfix) with ESMTP id 0AA4B21F8BF2 for ; Thu, 29 Nov 2012 13:04:37 -0800 (PST) Received: from [192.168.10.101] (a88-112-255-76.elisa-laajakaista.fi [88.112.255.76]) by dovecot.org (Postfix) with ESMTP id 9600F1AE87C3 for ; Thu, 29 Nov 2012 23:04:35 +0200 (EET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1085) From: Timo Sirainen In-Reply-To: <20121129162637.28724.48381.idtracker@ietfa.amsl.com> Date: Thu, 29 Nov 2012 23:04:35 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <8305E0CF-DFC8-49E4-B95E-D3E0BB575DE0@iki.fi> References: <20121129162637.28724.48381.idtracker@ietfa.amsl.com> To: imapext@ietf.org X-Mailer: Apple Mail (2.1085) Subject: Re: [imapext] I-D Action: draft-ietf-imapmove-command-05.txt X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Nov 2012 21:04:37 -0000 I guess I should have read this more closely earlier: > When a message is moved to a target mailbox, if the server is = capable=09 > of storing modification sequences for the mailbox, the server = MUST=09 > generate a new modification sequence that is higher than the = highest=09 > modification sequence of all messages in the mailbox and = assign it to=09 > the moved message. This seems to mean each moved message MUST have a new different = modification sequence. My server gives the same new modseq for all of = them. In general, maybe there shouldn't be any MUSTs at all in section 4? They = may unintentionally add extra restrictions that aren't in the base = documents. I now see another problem: > 4.3. RFC 4315, UIDPLUS >=20 > Servers supporting UIDPLUS [RFC4315] MUST send COPYUID in response = to > a UID MOVE command. This shouldn't be a MUST, since it adds a restriction not present in RFC = 4315: [RFC2359] implied that a server must always return COPYUID/APPENDUID data; thus suggesting that in such cases the server should return arbitrary data if the destination mailbox did not support persistent UIDs. This document adds the UIDNOTSTICKY response code to indicate that a mailbox does not support persistent UIDs, and stipulates that a UIDPLUS server does not return COPYUID/APPENDUID data when the COPY (or APPEND) destination mailbox has UIDNOTSTICKY status. From adrien@qbik.com Thu Nov 29 13:47:31 2012 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79CE021F8916 for ; Thu, 29 Nov 2012 13:47:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.561 X-Spam-Level: X-Spam-Status: No, score=-5.561 tagged_above=-999 required=5 tests=[AWL=-2.962, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id seJYLNiQYxX3 for ; Thu, 29 Nov 2012 13:47:31 -0800 (PST) Received: from smtp.qbik.com (smtp.qbik.com [210.55.214.35]) by ietfa.amsl.com (Postfix) with ESMTP id 98C3821F888A for ; Thu, 29 Nov 2012 13:47:30 -0800 (PST) Received: From [192.168.0.10] (unverified [192.168.0.10]) by SMTP Server [192.168.0.1] (WinGate SMTP Receiver v7.3.0 (Build 3470)) with SMTP id <0019380102@smtp.qbik.com>; Fri, 30 Nov 2012 10:48:08 +1300 From: "Adrien W. de Croy" To: "Timo Sirainen" , "imapext@ietf.org" Date: Thu, 29 Nov 2012 21:47:18 +0000 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; format=flowed; charset=utf-8 In-Reply-To: <8305E0CF-DFC8-49E4-B95E-D3E0BB575DE0@iki.fi> Message-Id: Mime-Version: 1.0 User-Agent: eM_Client/4.0.15145.0 Subject: Re: [imapext] I-D Action: draft-ietf-imapmove-command-05.txt X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: "Adrien W. de Croy" List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Nov 2012 21:47:31 -0000 =EF=BB=BF ------ Original Message ------ From: "Timo Sirainen" To: "imapext@ietf.org" Sent: 30/11/2012 10:04:35 a.m. Subject: Re: [imapext] I-D Action: draft-ietf-imapmove-command-05.txt >I guess I should have read this more closely earlier: > > >> >> When a message is moved to a target mailbox, if the server is capable= =09 >> of storing modification sequences for the mailbox, the server MUST= =09 >> generate a new modification sequence that is higher than the highest= =09 >> modification sequence of all messages in the mailbox and assign it= to=09 >> the moved message. >> > > >This seems to mean each moved message MUST have a new different modificati= on sequence. My server gives the same new modseq for all of them. > >In general, maybe there shouldn't be any MUSTs at all in section 4? They= may unintentionally add extra restrictions that aren't in the base documen= ts. I now see another problem: > maybe "a message" should be generalised to cover all the messages being=20 moved. E.g. When message(s) are moved to a target mailbox, if the server is capable=20 of storing modification sequences for the mailbox, the server MUST=20 generate a new modification sequence that is higher than the highest=20 modification sequence of all messages in the mailbox and assign it to=20 the moved message(s). >> >>4.3. RFC 4315, UIDPLUS >> >> Servers supporting UIDPLUS [RFC4315] MUST send COPYUID in response = to >> a UID MOVE command. >> > > >This shouldn't be a MUST, since it adds a restriction not present in RFC= 4315: > > [RFC2359] implied that a server must always return COPYUID/APPENDUID > data; thus suggesting that in such cases the server should return > arbitrary data if the destination mailbox did not support persistent > UIDs. This document adds the UIDNOTSTICKY response code to indicate > that a mailbox does not support persistent UIDs, and stipulates that > a UIDPLUS server does not return COPYUID/APPENDUID data when the COPY > (or APPEND) destination mailbox has UIDNOTSTICKY status. > persistence of UIDs is independent of allocation of them surely? a=20 message must have a UID, whether that's sticky or not. At the time of=20 the move, there must therefore be a UID? Adrien > > > >_______________________________________________ >imapext mailing list >imapext@ietf.org >https://www.ietf.org/mailman/listinfo/imapext > > From tss@iki.fi Thu Nov 29 15:50:51 2012 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D68A21F8B36 for ; Thu, 29 Nov 2012 15:50:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I4oB30tYy+tw for ; Thu, 29 Nov 2012 15:50:50 -0800 (PST) Received: from dovecot.org (dovecot.org [193.210.130.67]) by ietfa.amsl.com (Postfix) with ESMTP id 8A55C21F8B3F for ; Thu, 29 Nov 2012 15:50:50 -0800 (PST) Received: from [192.168.10.101] (a88-112-255-76.elisa-laajakaista.fi [88.112.255.76]) by dovecot.org (Postfix) with ESMTP id D6FDD1AE8949; Fri, 30 Nov 2012 01:50:48 +0200 (EET) Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Timo Sirainen In-Reply-To: Date: Fri, 30 Nov 2012 01:50:43 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: "Adrien W. de Croy" X-Mailer: Apple Mail (2.1085) Cc: "imapext@ietf.org" Subject: Re: [imapext] I-D Action: draft-ietf-imapmove-command-05.txt X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Nov 2012 23:50:51 -0000 On 29.11.2012, at 23.47, Adrien W. de Croy wrote: >>> When a message is moved to a target mailbox, if the server is = capable=09 >>> of storing modification sequences for the mailbox, the server = MUST=09 >>> generate a new modification sequence that is higher than the = highest=09 >>> modification sequence of all messages in the mailbox and assign = it to=09 >>> the moved message. >>=20 >> This seems to mean each moved message MUST have a new different = modification sequence. My server gives the same new modseq for all of = them. >>=20 >> In general, maybe there shouldn't be any MUSTs at all in section 4? = They may unintentionally add extra restrictions that aren't in the base = documents. I now see another problem: >>=20 > maybe "a message" should be generalised to cover all the messages = being moved. E.g. >=20 > When message(s) are moved to a target mailbox, if the server is = capable of storing modification sequences for the mailbox, the server = MUST generate a new modification sequence that is higher than the = highest modification sequence of all messages in the mailbox and assign = it to the moved message(s). That then reads more like all of the messages have the same modseq. = That's not necessarily true either. >>> 4.3. RFC 4315, UIDPLUS >>>=20 >>> Servers supporting UIDPLUS [RFC4315] MUST send COPYUID in response = to >>> a UID MOVE command. >>>=20 >>=20 >>=20 >> This shouldn't be a MUST, since it adds a restriction not present in = RFC 4315: >>=20 >> [RFC2359] implied that a server must always return COPYUID/APPENDUID >> data; thus suggesting that in such cases the server should return >> arbitrary data if the destination mailbox did not support persistent >> UIDs. This document adds the UIDNOTSTICKY response code to indicate >> that a mailbox does not support persistent UIDs, and stipulates that >> a UIDPLUS server does not return COPYUID/APPENDUID data when the COPY >> (or APPEND) destination mailbox has UIDNOTSTICKY status. >>=20 >=20 > persistence of UIDs is independent of allocation of them surely? a = message must have a UID, whether that's sticky or not. At the time of = the move, there must therefore be a UID? RFC 4315 clearly says that COPYUID doesn't need to be returned for such = mailboxes, so MOVE RFC shouldn't require it either. From ned.freed@mrochek.com Thu Nov 29 15:52:36 2012 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FB2E21F8B1B for ; Thu, 29 Nov 2012 15:52:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.591 X-Spam-Level: X-Spam-Status: No, score=-2.591 tagged_above=-999 required=5 tests=[AWL=0.008, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6pB5fPenHbcU for ; Thu, 29 Nov 2012 15:52:35 -0800 (PST) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id A54B221F8AD0 for ; Thu, 29 Nov 2012 15:52:35 -0800 (PST) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01ON78BKWF4W002D29@mauve.mrochek.com> for imapext@ietf.org; Thu, 29 Nov 2012 15:47:31 -0800 (PST) MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=utf-8; Format=flowed Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01ON76VC01SG00008T@mauve.mrochek.com>; Thu, 29 Nov 2012 15:47:28 -0800 (PST) Message-id: <01ON78BJDH9Q00008T@mauve.mrochek.com> Date: Thu, 29 Nov 2012 15:40:53 -0800 (PST) From: Ned Freed In-reply-to: "Your message dated Thu, 29 Nov 2012 21:47:18 +0000" References: <8305E0CF-DFC8-49E4-B95E-D3E0BB575DE0@iki.fi> To: "Adrien W. de Croy" Cc: Timo Sirainen , "imapext@ietf.org" Subject: Re: [imapext] I-D Action: draft-ietf-imapmove-command-05.txt X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Nov 2012 23:52:36 -0000 >  > ------ Original Message ------ > From: "Timo Sirainen" > To: "imapext@ietf.org" > Sent: 30/11/2012 10:04:35 a.m. > Subject: Re: [imapext] I-D Action: draft-ietf-imapmove-command-05.txt > >I guess I should have read this more closely earlier: > > > > > >> > >> When a message is moved to a target mailbox, if the server is capable > >> of storing modification sequences for the mailbox, the server MUST > >> generate a new modification sequence that is higher than the highest > >> modification sequence of all messages in the mailbox and assign it to > >> the moved message. > >> > > > > > >This seems to mean each moved message MUST have a new different modification sequence. My server gives the same new modseq for all of them. > > > >In general, maybe there shouldn't be any MUSTs at all in section 4? They may unintentionally add extra restrictions that aren't in the base documents. I now see another problem: > > > maybe "a message" should be generalised to cover all the messages being > moved. E.g. > When message(s) are moved to a target mailbox, if the server is capable > of storing modification sequences for the mailbox, the server MUST > generate a new modification sequence that is higher than the highest > modification sequence of all messages in the mailbox and assign it to > the moved message(s). That's my thought as well. (It's also how I read the original text.) This can be fixed in AUTH48. > >> > >>4.3. RFC 4315, UIDPLUS > >> > >> Servers supporting UIDPLUS [RFC4315] MUST send COPYUID in response to > >> a UID MOVE command. > >> > > > > > >This shouldn't be a MUST, since it adds a restriction not present in RFC 4315: > > > > [RFC2359] implied that a server must always return COPYUID/APPENDUID > > data; thus suggesting that in such cases the server should return > > arbitrary data if the destination mailbox did not support persistent > > UIDs. This document adds the UIDNOTSTICKY response code to indicate > > that a mailbox does not support persistent UIDs, and stipulates that > > a UIDPLUS server does not return COPYUID/APPENDUID data when the COPY > > (or APPEND) destination mailbox has UIDNOTSTICKY status. > > > persistence of UIDs is independent of allocation of them surely? a > message must have a UID, whether that's sticky or not. At the time of > the move, there must therefore be a UID? I confess to having very little sympathy with this one. I'm completely comfortable with keeping this requirement, and BTW there's nothing that says we can't impose additional requirements. That said, we could add "to any destintion that doesn't have UIDNOTSTICKY status" to the end. I'm also strongly opposed to removing compliance language. The point of having this section is to eliminate the need for readers to have to figure out requirements that arise from the interaction of this extension with other extensions. Ned From adrien@qbik.com Thu Nov 29 15:55:41 2012 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22C9321F8B20 for ; Thu, 29 Nov 2012 15:55:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.969 X-Spam-Level: X-Spam-Status: No, score=-4.969 tagged_above=-999 required=5 tests=[AWL=-2.370, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nEwasC1D+QL2 for ; Thu, 29 Nov 2012 15:55:40 -0800 (PST) Received: from smtp.qbik.com (smtp.qbik.com [210.55.214.35]) by ietfa.amsl.com (Postfix) with ESMTP id 2D50821F8B1A for ; Thu, 29 Nov 2012 15:55:36 -0800 (PST) Received: From [192.168.0.10] (unverified [192.168.0.10]) by SMTP Server [192.168.0.1] (WinGate SMTP Receiver v7.3.0 (Build 3470)) with SMTP id <0019380302@smtp.qbik.com>; Fri, 30 Nov 2012 12:56:15 +1300 From: "Adrien W. de Croy" To: "Timo Sirainen" Date: Thu, 29 Nov 2012 23:55: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.15145.0 Cc: "imapext@ietf.org" Subject: Re: [imapext] I-D Action: draft-ietf-imapmove-command-05.txt X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: "Adrien W. de Croy" List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Nov 2012 23:55:41 -0000 =EF=BB=BF ------ Original Message ------ From: "Timo Sirainen" >>maybe "a message" should be generalised to cover all the messages being= moved. E.g. >> >>When message(s) are moved to a target mailbox, if the server is capable= of storing modification sequences for the mailbox, the server MUST generat= e a new modification sequence that is higher than the highest modification= sequence of all messages in the mailbox and assign it to the moved message= (s). >> > > >That then reads more like all of the messages have the same modseq. That's= not necessarily true either. > fair enough >>>> >>>>4.3. RFC 4315, UIDPLUS >>>> >>>> Servers supporting UIDPLUS [RFC4315] MUST send COPYUID in response = to >>>> a UID MOVE command. >>>> >>>> >>> >>> >>> >>>This shouldn't be a MUST, since it adds a restriction not present in = RFC 4315: >>> >>>[RFC2359] implied that a server must always return COPYUID/APPENDUID >>>data; thus suggesting that in such cases the server should return >>>arbitrary data if the destination mailbox did not support persistent >>>UIDs. This document adds the UIDNOTSTICKY response code to indicate >>>that a mailbox does not support persistent UIDs, and stipulates that >>>a UIDPLUS server does not return COPYUID/APPENDUID data when the COPY >>>(or APPEND) destination mailbox has UIDNOTSTICKY status. >>> >>> >> >> >>persistence of UIDs is independent of allocation of them surely? a messa= ge must have a UID, whether that's sticky or not. At the time of the move,= there must therefore be a UID? >> > > >RFC 4315 clearly says that COPYUID doesn't need to be returned for such= mailboxes, so MOVE RFC shouldn't require it either. > > > maybe 4315 shouldn't have made that optional. Does it make any and all=20 use of UID undefined for such folders? Seems like a major breakage of=20 IMAP to me. But in any case, this is a new command - MOVE, and UID MOVE. With a new RFC. So rather than re-use COPYUID and make it optional (therefore useless,=20 since you can't rely on it), why not define something that is=20 mandatory, and we could maybe call it MOVEUID As for sticky or not UIDs, I'm not convinced these hens teeth should=20 have such a sharp bite. =20 Adrien > From tss@iki.fi Thu Nov 29 16:13:02 2012 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B6C921F8AA1 for ; Thu, 29 Nov 2012 16:13:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wPTcEm9cbH-G for ; Thu, 29 Nov 2012 16:13:02 -0800 (PST) Received: from dovecot.org (dovecot.org [193.210.130.67]) by ietfa.amsl.com (Postfix) with ESMTP id E2A7921F85C3 for ; Thu, 29 Nov 2012 16:12:54 -0800 (PST) Received: from [192.168.10.101] (a88-112-255-76.elisa-laajakaista.fi [88.112.255.76]) by dovecot.org (Postfix) with ESMTP id 7EF9E1AE8949; Fri, 30 Nov 2012 02:12:53 +0200 (EET) Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Timo Sirainen In-Reply-To: Date: Fri, 30 Nov 2012 02:12:53 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <16D79FAD-C79A-401A-947A-2979E5330AEF@iki.fi> References: To: "Adrien W. de Croy" X-Mailer: Apple Mail (2.1085) Cc: "imapext@ietf.org" Subject: Re: [imapext] I-D Action: draft-ietf-imapmove-command-05.txt X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Nov 2012 00:13:02 -0000 On 30.11.2012, at 1.55, Adrien W. de Croy wrote: >>> persistence of UIDs is independent of allocation of them surely? a = message must have a UID, whether that's sticky or not. At the time of = the move, there must therefore be a UID? >>=20 >>=20 >> RFC 4315 clearly says that COPYUID doesn't need to be returned for = such mailboxes, so MOVE RFC shouldn't require it either. >=20 > maybe 4315 shouldn't have made that optional. Does it make any and = all use of UID undefined for such folders? Seems like a major breakage = of IMAP to me. >=20 > But in any case, this is a new command - MOVE, and UID MOVE. >=20 > With a new RFC. >=20 > So rather than re-use COPYUID and make it optional (therefore useless, = since you can't rely on it), why not define something that is mandatory, = and we could maybe call it MOVEUID >=20 > As for sticky or not UIDs, I'm not convinced these hens teeth should = have such a sharp bite. =20 Well, my server advertises UIDPLUS, because it works pretty much = everywhere. But there are some backends where returning = COPYUID/APPENDUID would be very complex/expensive (e.g. proxying to = another IMAP server without UIDPLUS support), so it just doesn't return = it. I guess that's already on the grey area with UIDPLUS, but I'd rather = not make it completely wrong when MOVE is advertised. :) From ned.freed@mrochek.com Thu Nov 29 18:20:54 2012 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F24EE21F889A for ; Thu, 29 Nov 2012 18:20:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.592 X-Spam-Level: X-Spam-Status: No, score=-2.592 tagged_above=-999 required=5 tests=[AWL=0.007, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ii5d+g0TYePL for ; Thu, 29 Nov 2012 18:20:53 -0800 (PST) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id 3DB5C21F87F5 for ; Thu, 29 Nov 2012 18:20:53 -0800 (PST) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01ON7DHHZZXC002KVV@mauve.mrochek.com> for imapext@ietf.org; Thu, 29 Nov 2012 18:15:50 -0800 (PST) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01ON76VC01SG00008T@mauve.mrochek.com>; Thu, 29 Nov 2012 18:15:48 -0800 (PST) Message-id: <01ON7DHGEQX000008T@mauve.mrochek.com> Date: Thu, 29 Nov 2012 17:58:16 -0800 (PST) From: Ned Freed In-reply-to: "Your message dated Fri, 30 Nov 2012 02:12:53 +0200" <16D79FAD-C79A-401A-947A-2979E5330AEF@iki.fi> MIME-version: 1.0 Content-type: TEXT/PLAIN References: <16D79FAD-C79A-401A-947A-2979E5330AEF@iki.fi> To: Timo Sirainen Cc: "Adrien W. de Croy" , "imapext@ietf.org" Subject: Re: [imapext] I-D Action: draft-ietf-imapmove-command-05.txt X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Nov 2012 02:20:54 -0000 > On 30.11.2012, at 1.55, Adrien W. de Croy wrote: > >>> persistence of UIDs is independent of allocation of them surely? a message must have a UID, whether that's sticky or not. At the time of the move, there must therefore be a UID? > >> > >> > >> RFC 4315 clearly says that COPYUID doesn't need to be returned for such mailboxes, so MOVE RFC shouldn't require it either. > > > > maybe 4315 shouldn't have made that optional. Does it make any and all use of UID undefined for such folders? Seems like a major breakage of IMAP to me. > > > > But in any case, this is a new command - MOVE, and UID MOVE. > > > > With a new RFC. > > > > So rather than re-use COPYUID and make it optional (therefore useless, since you can't rely on it), why not define something that is mandatory, and we could maybe call it MOVEUID > > > > As for sticky or not UIDs, I'm not convinced these hens teeth should have such a sharp bite. > Well, my server advertises UIDPLUS, because it works pretty much everywhere. > But there are some backends where returning COPYUID/APPENDUID would be very > complex/expensive (e.g. proxying to another IMAP server without UIDPLUS > support), so it just doesn't return it. I guess that's already on the grey area > with UIDPLUS, but I'd rather not make it completely wrong when MOVE is > advertised. :) I read this as saying that your server never returns COPYUID/APPENDUID even when the backend you're using supports it If that's the case, then I'm afraid your server isn't really compliant with RFC 4315. RFC 4315 relaxes the COPYUID requirement, but only to a SHOULD (section 3), and specifies two exceptions: (1) When the mailbox is protected from reads but allows writes (SHOULD NOT return) (2) When UIDNOTSTICKY is set (MAY omit). This gives sufficient grounds for not returning it when the back end can't provide the necessary information, but does not justify not returning it in cases where the backend is capable of doing so. Getting back to the specification at hand, given that RFC 4315 only says SHOULD, not MUST, that's a case for changing the MUST to a SHOULD in section 4.3. But as I pointed out previously, I'm also OK with keeping the MUST if people think that's what needs to be there. As for process issues, I think if we get agrement on the list and Barry agrees we can make this change during AUTH48. Ned From tss@iki.fi Thu Nov 29 18:40:36 2012 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB4A621F8933 for ; Thu, 29 Nov 2012 18:40:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rr+zpiNs-+gh for ; Thu, 29 Nov 2012 18:40:36 -0800 (PST) Received: from dovecot.org (dovecot.org [193.210.130.67]) by ietfa.amsl.com (Postfix) with ESMTP id 331D321F8931 for ; Thu, 29 Nov 2012 18:40:35 -0800 (PST) Received: from [192.168.10.101] (a88-112-255-76.elisa-laajakaista.fi [88.112.255.76]) by dovecot.org (Postfix) with ESMTP id 7D4C31AE876C; Fri, 30 Nov 2012 04:40:34 +0200 (EET) Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Timo Sirainen In-Reply-To: <01ON7DHGEQX000008T@mauve.mrochek.com> Date: Fri, 30 Nov 2012 04:40:29 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <510DE073-65F1-4F35-AE1E-E4BE20A13CB0@iki.fi> References: <16D79FAD-C79A-401A-947A-2979E5330AEF@iki.fi> <01ON7DHGEQX000008T@mauve.mrochek.com> To: Ned Freed X-Mailer: Apple Mail (2.1085) Cc: "Adrien W. de Croy" , "imapext@ietf.org" Subject: Re: [imapext] I-D Action: draft-ietf-imapmove-command-05.txt X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Nov 2012 02:40:36 -0000 On 30.11.2012, at 3.58, Ned Freed wrote: >> Well, my server advertises UIDPLUS, because it works pretty much = everywhere. >> But there are some backends where returning COPYUID/APPENDUID would = be very >> complex/expensive (e.g. proxying to another IMAP server without = UIDPLUS >> support), so it just doesn't return it. I guess that's already on the = grey area >> with UIDPLUS, but I'd rather not make it completely wrong when MOVE = is >> advertised. :) >=20 > I read this as saying that your server never returns COPYUID/APPENDUID = even > when the backend you're using supports it If that's the case, then I'm = afraid > your server isn't really compliant with RFC 4315. Only with some very rarely used backends/configurations. > RFC 4315 relaxes the COPYUID > requirement, but only to a SHOULD (section 3), and specifies two > exceptions: >=20 > (1) When the mailbox is protected from reads but allows writes (SHOULD = NOT > return) Oh, this is actually a good point that I hadn't noticed / thought of = before. If mailbox ACLs prevent read access, the COPY command shouldn't = expose how many messages it contains or when it gets new messages by = sending COPYUID. This would be important for MOVE as well. From ned.freed@mrochek.com Thu Nov 29 22:40:27 2012 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27A5121F89BE for ; Thu, 29 Nov 2012 22:40:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.592 X-Spam-Level: X-Spam-Status: No, score=-2.592 tagged_above=-999 required=5 tests=[AWL=0.007, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hX0Q8aXsqyjr for ; Thu, 29 Nov 2012 22:40:26 -0800 (PST) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id 038AF21F89B5 for ; Thu, 29 Nov 2012 22:40:25 -0800 (PST) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01ON7MK9LH7K002J2B@mauve.mrochek.com> for imapext@ietf.org; Thu, 29 Nov 2012 22:35:23 -0800 (PST) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01ON7KPECCIO00008T@mauve.mrochek.com>; Thu, 29 Nov 2012 22:35:20 -0800 (PST) Message-id: <01ON7MK7EA9M00008T@mauve.mrochek.com> Date: Thu, 29 Nov 2012 21:48:05 -0800 (PST) From: Ned Freed In-reply-to: "Your message dated Fri, 30 Nov 2012 04:40:29 +0200" <510DE073-65F1-4F35-AE1E-E4BE20A13CB0@iki.fi> MIME-version: 1.0 Content-type: TEXT/PLAIN References: <16D79FAD-C79A-401A-947A-2979E5330AEF@iki.fi> <01ON7DHGEQX000008T@mauve.mrochek.com> <510DE073-65F1-4F35-AE1E-E4BE20A13CB0@iki.fi> To: Timo Sirainen Cc: "Adrien W. de Croy" , Ned Freed , "imapext@ietf.org" Subject: Re: [imapext] I-D Action: draft-ietf-imapmove-command-05.txt X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Nov 2012 06:40:27 -0000 > > RFC 4315 relaxes the COPYUID > > requirement, but only to a SHOULD (section 3), and specifies two > > exceptions: > > > > (1) When the mailbox is protected from reads but allows writes (SHOULD NOT > > return) > Oh, this is actually a good point that I hadn't noticed / thought of before. > If mailbox ACLs prevent read access, the COPY command shouldn't expose how many > messages it contains or when it gets new messages by sending COPYUID. This > would be important for MOVE as well. And when you put it that way, it's an information exposure issue that IMO requires us to use SHOULD. I'm therefore changing the paragraph to read: Servers supporting UIDPLUS [RFC4315] SHOULD send COPYUID in response to a UID MOVE command. For additional information see Section 3 of [RFC4315]. Does this address the issue? Ned From tss@iki.fi Thu Nov 29 22:54:50 2012 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD2E921F897A for ; Thu, 29 Nov 2012 22:54:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id msQ-6PMgrXBr for ; Thu, 29 Nov 2012 22:54:50 -0800 (PST) Received: from dovecot.org (dovecot.org [193.210.130.67]) by ietfa.amsl.com (Postfix) with ESMTP id 2815A21F8946 for ; Thu, 29 Nov 2012 22:54:49 -0800 (PST) Received: from [10.217.1.130] (unknown [193.184.212.30]) by dovecot.org (Postfix) with ESMTP id 9FFB21AE8943; Fri, 30 Nov 2012 08:54:47 +0200 (EET) Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Timo Sirainen In-Reply-To: <01ON7MK7EA9M00008T@mauve.mrochek.com> Date: Fri, 30 Nov 2012 08:54:47 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <16D79FAD-C79A-401A-947A-2979E5330AEF@iki.fi> <01ON7DHGEQX000008T@mauve.mrochek.com> <510DE073-65F1-4F35-AE1E-E4BE20A13CB0@iki.fi> <01ON7MK7EA9M00008T@mauve.mrochek.com> To: Ned Freed X-Mailer: Apple Mail (2.1085) Cc: "Adrien W. de Croy" , "imapext@ietf.org" Subject: Re: [imapext] I-D Action: draft-ietf-imapmove-command-05.txt X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Nov 2012 06:54:50 -0000 On 30.11.2012, at 7.48, Ned Freed wrote: >>> RFC 4315 relaxes the COPYUID >>> requirement, but only to a SHOULD (section 3), and specifies two >>> exceptions: >>>=20 >>> (1) When the mailbox is protected from reads but allows writes = (SHOULD NOT >>> return) >=20 >> Oh, this is actually a good point that I hadn't noticed / thought of = before. >> If mailbox ACLs prevent read access, the COPY command shouldn't = expose how many >> messages it contains or when it gets new messages by sending COPYUID. = This >> would be important for MOVE as well. >=20 > And when you put it that way, it's an information exposure issue that = IMO > requires us to use SHOULD. I'm therefore changing the paragraph to = read: >=20 > Servers supporting UIDPLUS [RFC4315] SHOULD send COPYUID in response = to a UID > MOVE command. For additional information see Section 3 of [RFC4315]. >=20 > Does this address the issue? Works for me. From alexey.melnikov@isode.com Fri Nov 30 08:30:04 2012 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 201B121F8B5A for ; Fri, 30 Nov 2012 08:30:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.534 X-Spam-Level: X-Spam-Status: No, score=-102.534 tagged_above=-999 required=5 tests=[AWL=0.065, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FJ1ak6TGne9r for ; Fri, 30 Nov 2012 08:30:03 -0800 (PST) Received: from statler.isode.com (statler.isode.com [62.3.217.254]) by ietfa.amsl.com (Postfix) with ESMTP id B73E621F8B48 for ; Fri, 30 Nov 2012 08:30:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1354293001; d=isode.com; s=selector; i=@isode.com; bh=GIDMvF8bs8kxC1sYr9UX8RWSlmWH4hSKS/XME3yOvuQ=; 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=Hb/otwUBgit4nUQcUsKKS642ByI2NjUSMN1/sIVoBw1l1Pk+DIBNTAP8V28pBgbfJ2RwKw b09pu7GBkxIha8u6hoz/DnzMUDoz4iaHFZ4HoGYseoXgTyIPrDLQrbW6TaTqVIYa5Efe0V SXvBqrrGFkIVnBFHSyaUeJyuZm3a9og=; Received: from [172.16.1.29] (shiny.isode.com [62.3.217.250]) by statler.isode.com (submission channel) via TCP with ESMTPA id ; Fri, 30 Nov 2012 16:30:01 +0000 Message-ID: <50B8DF0A.3050903@isode.com> Date: Fri, 30 Nov 2012 16:30:02 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 To: Ned Freed References: <8305E0CF-DFC8-49E4-B95E-D3E0BB575DE0@iki.fi> <01ON78BJDH9Q00008T@mauve.mrochek.com> In-Reply-To: <01ON78BJDH9Q00008T@mauve.mrochek.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-transfer-encoding: quoted-printable Cc: "Adrien W. de Croy" , Timo Sirainen , "imapext@ietf.org" Subject: Re: [imapext] I-D Action: draft-ietf-imapmove-command-05.txt X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Nov 2012 16:30:04 -0000 On 29/11/2012 23:40, Ned Freed wrote: >> =EF=BB=BF >> ------ Original Message ------ >> From: "Timo Sirainen" >> To: "imapext@ietf.org" >> Sent: 30/11/2012 10:04:35 a.m. >> Subject: Re: [imapext] I-D Action: draft-ietf-imapmove-command-05.txt >> >I guess I should have read this more closely earlier: >> > >> > >> >> >> >> When a message is moved to a target mailbox, if the server is=20 >> capable >> >> of storing modification sequences for the mailbox, the server=20 >> MUST >> >> generate a new modification sequence that is higher than the=20 >> highest >> >> modification sequence of all messages in the mailbox and=20 >> assign it to >> >> the moved message. >> >> >> > >> > >> >This seems to mean each moved message MUST have a new different=20 >> modification sequence. My server gives the same new modseq for all of=20 >> them. >> > >> >In general, maybe there shouldn't be any MUSTs at all in section 4?=20 >> They may unintentionally add extra restrictions that aren't in the=20 >> base documents. I now see another problem: >> > >> maybe "a message" should be generalised to cover all the messages being >> moved. E.g. > >> When message(s) are moved to a target mailbox, if the server is capable >> of storing modification sequences for the mailbox, the server MUST >> generate a new modification sequence that is higher than the highest >> modification sequence of all messages in the mailbox and assign it to >> the moved message(s). > > That's my thought as well. (It's also how I read the original text.) That was the intent. The server can assign different modseqs or the same=20 modseqs to multiple messages being moved. > This can be fixed in AUTH48. Agreed. >> >> >> >>4.3. RFC 4315, UIDPLUS >> >> >> >> Servers supporting UIDPLUS [RFC4315] MUST send COPYUID in=20 >> response to >> >> a UID MOVE command. >> >> >> > >> > >> >This shouldn't be a MUST, since it adds a restriction not present in=20 >> RFC 4315: >> > >> > [RFC2359] implied that a server must always return COPYUID/APPENDUID >> > data; thus suggesting that in such cases the server should return >> > arbitrary data if the destination mailbox did not support persistent >> > UIDs. This document adds the UIDNOTSTICKY response code to indicate >> > that a mailbox does not support persistent UIDs, and stipulates that >> > a UIDPLUS server does not return COPYUID/APPENDUID data when the COPY >> > (or APPEND) destination mailbox has UIDNOTSTICKY status. >> > > >> persistence of UIDs is independent of allocation of them surely? a >> message must have a UID, whether that's sticky or not. At the time of >> the move, there must therefore be a UID? > > I confess to having very little sympathy with this one. I'm completely > comfortable with keeping this requirement, and BTW there's nothing that > says we can't impose additional requirements. > > That said, we could add "to any destintion that doesn't have UIDNOTSTICKY > status" to the end. Agreed. > I'm also strongly opposed to removing compliance language. The point=20 > of having > this section is to eliminate the need for readers to have to figure out > requirements that arise from the interaction of this extension with other > extensions. Exactly.