From jkt@flaska.net Sat Sep 1 03:24: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 E345121F84EE for ; Sat, 1 Sep 2012 03:24:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.852 X-Spam-Level: X-Spam-Status: No, score=-0.852 tagged_above=-999 required=5 tests=[AWL=0.098, BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TKB65O0zHUzb for ; Sat, 1 Sep 2012 03:24:36 -0700 (PDT) Received: from ipo2-out.fzu.cz (ipo2-out.fzu.cz [147.231.27.21]) by ietfa.amsl.com (Postfix) with ESMTP id 37C8D21F8491 for ; Sat, 1 Sep 2012 03:24:34 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AoQCAIThQVCT5xpZgWdsb2JhbABEhgS1GyIBARYmJ4IgAQEEASMPAQVABgsLGAICBQ0BBQMLAgIJAwIBAgFFEwgBAReHbAYEqAeSSoEhigUBg2kBgg2BEgOVWIEUkWuBVgIHGg X-IronPort-AV: E=Sophos;i="4.80,351,1344204000"; d="scan'208";a="305815" Received: from freja.fzu.cz ([147.231.26.89]) by ipo2-out.fzu.cz with ESMTP; 01 Sep 2012 12:24:32 +0200 Received: from svist.flaska.net (ip-89-176-26-68.net.upcbroadband.cz [89.176.26.68]) by freja.fzu.cz (Postfix) with ESMTPSA id 342C63DA82 for ; Sat, 1 Sep 2012 12:24:32 +0200 (CEST) Message-ID: <5041E240.3050005@flaska.net> Date: Sat, 01 Sep 2012 12:24:00 +0200 From: =?UTF-8?B?SmFuIEt1bmRyw6F0?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:9.0) Gecko/20120128 Thunderbird/9.0 MIME-Version: 1.0 To: imapext@ietf.org References: <5040D39D.1000207@flaska.net> <703929f4-254d-45d6-8ea5-793b27290235@email.android.com> <195857373.541921.1346440878117.JavaMail.root@zimbra.com> <01OJPE8YAE9M0006TF@mauve.mrochek.com> <50413296.7050808@flaska.net> <01OJPXELHPKK0006TF@mauve.mrochek.com> In-Reply-To: <01OJPXELHPKK0006TF@mauve.mrochek.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [imapext] Problem with reusing untagged COPYUID in pipelined UID MOVE or MOVE 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, 01 Sep 2012 10:24:37 -0000 On 09/01/12 04:24, Ned Freed wrote: > But in a way this is all moot. Even if this section didn't exist we can > apply whatever restrictions we want to MOVE. The fact that this section > exists > is only an indication that there is ample precedent in IMAP for having such > restrictions. Ned, I agree. What I'm saying is that UID MOVE, as defined in -01, can have surprising results when pipelined, and am seeking a solution to fix this. If the solution ends up as "don't pipeline UID MOVE" *and* this is clearly documented in the draft, that will be acceptable to me, even if I still believe that there are ways to make this case safe and without any ambiguity while enabling pipelining. > Doesn't follow. If the semantics and capabilities of a COPY/STORE/EXPUNGE > sequence were identical to MOVE, there would be no need for MOVE. But > the semantics rather obviously aren't the same. Please keep in mind that I have never discussed MOVE, just UID MOVE. Everything I said about the ambiguity applies to UID MOVE, I've been ignoring MOVE altogether. The draft says this: > The UID MOVE command has the same effect as a sequence of UID COPY, > UID STORE +FLAGS.SILENT \DELETED and UID EXPUNGE, with the added > requirement that each message SHOULD either be moved or unaffected. > The server SHOULD NOT leave a message in neither or both mailboxes > afterwards (even if the server returns a tagged NO response). > > UID MOVE is the same as the three-command sequence in all other > respects, which implies that extensions which affect the three- > command sequence also affect UID MOVE, and that response codes such > as COPYUID, TRYCREATE and so on should be sent as appropriate. To me, this means that if one can pipeline two occurences of a (UID COPY, UID STORE, UID EXPUNGE) sequence, it would be a very unexpected side effect if one could not pipeline two UID MOVE commands. It looks like Timo agrees with me on this one. > Then the first question that needs to be asked is whether or not pipelining > overlapping moves is a capability with a either a significant use-case > of its > own or is something that comes up willy-nilly and is also difficult for > clients > to avoid. > > Once that is asssed the costs of addressing the issue can be weighed > against > the benefits that will accrue in the client space. Again, I agree completely. Let's ban UID MOVE pipelining or make it safe to pipeline. Either will work for me. > And no, I don't care if there is concern that it might come up sometime or > somewhere. The IMAP extensions space has quite a few examples of extensions > that were made overly complex precisely because of this sort of vague > concern. > That's why this work was chartered as a narrowly focused effort. My client uses pipelining aggressively. Copying and moving is handled by the same code path. Immediately after a mouse drag is performed, no matter whether there's another UID COPY in progress, an auxiliary "task" is instantiated. If the current operation is to "move messages", a second task for UID STORE is created and marked as depending on the first, copying one, and a third task which will eventually do UID EXPUNGE is created and marked as depending on the second one. The first task doing the UID COPY is activated more or less instantly. There's a generic framework which is responsible for activating the depending tasks only when their dependency has finished successfully (i.e. one can only call UID FETCH after the mailbox has been selected, one can SELECT only after the LOGIN has completed, etc). It will "kill" those tasks whose parents have not succeeded. This layer is common to all commands. Now, what happens when there's a slow network being involved and the user moves mouse fast enough? Due to the ordering of the tasks I've mentioned earlier, the communication might look like the following: C: y1 UID COPY 2 foo # UID STORE and UID EXPUNGE are pending on y1's completion C: y2 UID COPY 2 bar # another pair of UID STORE, UID EXPUNGE pending S: y1 OK [COPYUID ...] done C: y3 UID STORE 2 (+FLAGS.SILENT \Deleted) S: y2 OK [COPYUID ...] done C: y4 UID STORE 2 (+FLAGS.SILENT \Deleted) S: y3 OK done C: y5 UID EXPUNGE 2 S: y4 OK done C: y6 UID EXPUNGE 2 S: * VANISHED 2 S: y5 OK done S: y6 OK done One can argue that my client could take care to never schedule more than one concurrent "move" operation. Yes, it could. This corner case is one of the motivations for UID MOVE being proposed in the first place -- so that clients don't have to "cope with partial failures and side effects", to quote the draft. (My client will not expunge messages when UIDPLUS is not announced. I did not dare to temporarily remove the "other" \Deleted flags, call EXPUNGE and restore the \Deleted back as this process is inherently racy.) In presence of UID MOVE extension, I would not create a CopyMessagesTask, but a MoveMessagesTask, and the communication would look like this: C: y1 UID MOVE 2 foo # network is slow to respond C: y2 UID MOVE 2 bar S: * OK [COPYUID ...] copied S: * VANISHED 2 S: y1 OK done S: y2 OK done At this point, my client actually has no way to know where the message got copied to. That's a small regression compared to the UID COPY/UID STORE/UID EXPUNGE sequence. So, a quick summary: - There's at least one client which will happily pipeline UID MOVE. No other client has implemented the UID MOVE draft yet, AFAIK. - Pipelined UID MOVE (even on non-overlapping message sets) means that the client cannot reasonably infer the target mailbox where the messages got moved to, removing the benefits of the COPYUID response. I can live with this (in fact, to be honest with you, the cache implementation which I'm using now does not support reference counting, so it ignores COPYUID for the time being). However, as we are evaluating a new extension, let's take our time to make it good enough. Therefore, I propose that we choose one of the following results: 0) Do nothing. 1) Ban "MOVE" and "UID MOVE" pipelining due to ambiguity. 2) Ban "MOVE" pipelining due to ambiguity and add a note that "UID MOVE" pipelining leads to COPYUID being unusable. 3) Ban "MOVE" pipelining due to ambiguity, replace COPYUID with something that contains the reference to the target mailbox or the command's tag. I find 3) to be the best. 2) is OK for me, 1) is bad, 0) is the worst, IMHO. But before choosing 0), please show me why I'm wrong. With kind regards, Jan -- Trojita, a fast e-mail client -- http://trojita.flaska.net/ From barryleiba.mailing.lists@gmail.com Sat Sep 1 08:29: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 B9C4121F87CB for ; Sat, 1 Sep 2012 08:29:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.017 X-Spam-Level: X-Spam-Status: No, score=-103.017 tagged_above=-999 required=5 tests=[AWL=-0.040, 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 F9r5FqnUN+vU for ; Sat, 1 Sep 2012 08:29:38 -0700 (PDT) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id C92B921F87C9 for ; Sat, 1 Sep 2012 08:29:37 -0700 (PDT) Received: by lahm15 with SMTP id m15so3414337lah.31 for ; Sat, 01 Sep 2012 08:29:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type; bh=OgUiqgR+oOqttU94JhcQNWODHXGIHSSJMsxhRyGR1g8=; b=uhH8UaKOQURWBoKlFSWKXC3lJBHGDEZYdvKqi1jpN6akrL0NNZx0Z2UV39nvAVxu/Q BXJX1qAQ2q302pbSkEMEcyc+KA2tvpSr7UwRpMVx1zbnzBYcQnrmclmqDT3DJyfWfjbF uF4am6ZnQRnkw/OARn3ErJzG796LXfSrGbmzDtZwZFLn72NUb5tdF6EV1iDHz5jAI2JB 3LmBZCBHMSFBi7LjCZzlD3/KnWlqO5huFsjFCtJju275VFQtzmnesnJjHFWGekU2cICs eVh+pycgFR6zlJAUxUtInUsnbjIu0YYQNA/OS+r7RMOnfwGCsGDIRyegpPzK9EeQf+iI xsCQ== MIME-Version: 1.0 Received: by 10.112.31.197 with SMTP id c5mr3680598lbi.50.1346513376383; Sat, 01 Sep 2012 08:29:36 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.112.91.33 with HTTP; Sat, 1 Sep 2012 08:29:36 -0700 (PDT) In-Reply-To: <01OJPXELHPKK0006TF@mauve.mrochek.com> References: <5040D39D.1000207@flaska.net> <703929f4-254d-45d6-8ea5-793b27290235@email.android.com> <195857373.541921.1346440878117.JavaMail.root@zimbra.com> <01OJPE8YAE9M0006TF@mauve.mrochek.com> <50413296.7050808@flaska.net> <01OJPXELHPKK0006TF@mauve.mrochek.com> Date: Sat, 1 Sep 2012 11:29:36 -0400 X-Google-Sender-Auth: ID-gaYMvt5KXhO3RQDXvRUe-Qnw Message-ID: From: Barry Leiba To: imapext@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [imapext] Problem with reusing untagged COPYUID in pipelined UID MOVE or MOVE 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, 01 Sep 2012 15:29:38 -0000 > But in a way this is all moot. Even if this section didn't exist we can > apply whatever restrictions we want to MOVE. The fact that this section > exists is only an indication that there is ample precedent in IMAP for having > such restrictions. Absolutely; this document is defining a new command, and it can put whatever restrictions it likes on the use of that new command. If the restrictions start developing in a way that seems to violate the "gestalt" of IMAP, participants can object and things can go in a different direction. Restrictions on pipelining do not seem to me to violate the IMAP gestalt at all. > Doesn't follow. If the semantics and capabilities of a COPY/STORE/EXPUNGE > sequence were identical to MOVE, there would be no need for MOVE. But > the semantics rather obviously aren't the same. I think this is a very important comment, and I think it leads to something: Let me strongly suggest that this document *downplay* the COPY + STORE + EXPUNGE aspect, and focus on the actual result. We're stuck in the COPY + STORE + EXPUNGE mindset because it's the way we used to do things, but I do NOT think it does the document or the proposed function any favours to make a point of saying that it has to be equivalent to that. The *most* I would say about it is the text in the Overview that says that COPY + STORE + EXPUNGE is the way this has been done heretofore, and that it's the intent that this command replace that mechanism with something having a similar effect. I think that leaning on the COPY + STORE + EXPUNGE model beyond that is taking things in the wrong direction. Specifically: - I would re-word the second paragraph of Section 3 to talk about the result of the command, NOT in terms of COPY + STORE + EXPUNGE. - I would re-word the penultimate paragraph of Section 3 to put it in terms of COPY only; I don't think it's necessary to go beyond that here. - I would re-word Section 4.2 to this: 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. (And you need a normative reference to 4314 (yes, you do).) - I would re-word the first paragraph of Section 4.3 to this: Servers supporting UIDPLUS [RFC4315] MUST send COPYUID in response to a UID MOVE command. The second paragraph also needs some re-wording. - The second Section 4.3 needs to be renumbered to 4.4, and I would re-word that this way: 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. Barry, as participant From ned.freed@mrochek.com Sun Sep 2 19:32: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 4A44021F8476 for ; Sun, 2 Sep 2012 19:32:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.537 X-Spam-Level: X-Spam-Status: No, score=-2.537 tagged_above=-999 required=5 tests=[AWL=0.062, 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 Dt-OZiOh26Vh for ; Sun, 2 Sep 2012 19:32:05 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id E926A21F8433 for ; Sun, 2 Sep 2012 19:32:04 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OJSIC9JTZK003EFU@mauve.mrochek.com> for imapext@ietf.org; Sun, 2 Sep 2012 19:26:58 -0700 (PDT) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OJFFFOH4280006TF@mauve.mrochek.com>; Sun, 2 Sep 2012 19:26:54 -0700 (PDT) Message-id: <01OJSIC77SSK0006TF@mauve.mrochek.com> Date: Sun, 02 Sep 2012 19:19:54 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Sat, 01 Sep 2012 11:29:36 -0400" MIME-version: 1.0 Content-type: TEXT/PLAIN References: <5040D39D.1000207@flaska.net> <703929f4-254d-45d6-8ea5-793b27290235@email.android.com> <195857373.541921.1346440878117.JavaMail.root@zimbra.com> <01OJPE8YAE9M0006TF@mauve.mrochek.com> <50413296.7050808@flaska.net> <01OJPXELHPKK0006TF@mauve.mrochek.com> To: Barry Leiba Cc: imapext@ietf.org Subject: Re: [imapext] Problem with reusing untagged COPYUID in pipelined UID MOVE or MOVE 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, 03 Sep 2012 02:32:06 -0000 > > But in a way this is all moot. Even if this section didn't exist we can > > apply whatever restrictions we want to MOVE. The fact that this section > > exists is only an indication that there is ample precedent in IMAP for having > > such restrictions. > Absolutely; this document is defining a new command, and it can put > whatever restrictions it likes on the use of that new command. If the > restrictions start developing in a way that seems to violate the > "gestalt" of IMAP, participants can object and things can go in a > different direction. Restrictions on pipelining do not seem to me to > violate the IMAP gestalt at all. Agreed. That said, if there's a real use-case for pipelining overlapped MOVEs and the cost of addressing the issue is low, I don't object to following that path either. > > Doesn't follow. If the semantics and capabilities of a COPY/STORE/EXPUNGE > > sequence were identical to MOVE, there would be no need for MOVE. But > > the semantics rather obviously aren't the same. > I think this is a very important comment, and I think it leads to something: > Let me strongly suggest that this document *downplay* the COPY + STORE > + EXPUNGE aspect, and focus on the actual result. We're stuck in the > COPY + STORE + EXPUNGE mindset because it's the way we used to do > things, but I do NOT think it does the document or the proposed > function any favours to make a point of saying that it has to be > equivalent to that. I didn't intend to take it that far but now that you have I find myself liking the approach a lot. If we need more explanation than what would result from your changes below perhaps the right thing to do is to explain this as its own thing first, but then relate it to COPY/STORE/EXPUNGE but emphasing the *differences*. > The *most* I would say about it is the text in the Overview that says > that COPY + STORE + EXPUNGE is the way this has been done heretofore, > and that it's the intent that this command replace that mechanism with > something having a similar effect. I think that leaning on the COPY + > STORE + EXPUNGE model beyond that is taking things in the wrong > direction. > Specifically: > - I would re-word the second paragraph of Section 3 to talk about the > result of the command, NOT in terms of COPY + STORE + EXPUNGE. > - I would re-word the penultimate paragraph of Section 3 to put it in > terms of COPY only; I don't think it's necessary to go beyond that > here. > - I would re-word Section 4.2 to this: > 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. > (And you need a normative reference to 4314 (yes, you do).) On consideration I think you are correct. You can't talk about performing an operation on something without knowing for sure what that something is, which makes this normative. > - I would re-word the first paragraph of Section 4.3 to this: > Servers supporting UIDPLUS [RFC4315] MUST send COPYUID > in response to a UID MOVE command. > The second paragraph also needs some re-wording. > - The second Section 4.3 needs to be renumbered to 4.4, and I would > re-word that this way: > 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. I have no objection to any of these changes. Ned From arnt@gulbrandsen.priv.no Tue Sep 4 14:17:23 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 AA25521E8083 for ; Tue, 4 Sep 2012 14:17:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.53 X-Spam-Level: X-Spam-Status: No, score=-1.53 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DATE_IN_PAST_06_12=1.069] 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 WPT4ORAQTw6C for ; Tue, 4 Sep 2012 14:17:23 -0700 (PDT) Received: from strange.aox.org (strange.aox.org [IPv6:2001:4d88:100c::1]) by ietfa.amsl.com (Postfix) with ESMTP id B1D0A21E8040 for ; Tue, 4 Sep 2012 14:17:22 -0700 (PDT) Received: from fri.gulbrandsen.priv.no (unknown [127.0.0.1]) by strange.aox.org (Postfix) with ESMTP id 24271F8FC3A; Tue, 4 Sep 2012 21:17:22 +0000 (UTC) Received: from arnt@gulbrandsen.priv.no by fri.gulbrandsen.priv.no (Archiveopteryx 3.1.4) with esmtpsa id 1346793441-29695-29694/11/2; Tue, 4 Sep 2012 21:17:21 +0000 Message-Id: <5045D0FA.3030107@gulbrandsen.priv.no> Date: Tue, 4 Sep 2012 11:59:22 +0200 From: Arnt Gulbrandsen User-Agent: Mozilla/5.0 (X11; Linux i686; rv:15.0) Gecko/20120827 Thunderbird/15.0 Mime-Version: 1.0 To: imapext@ietf.org References: <5040D39D.1000207@flaska.net> <703929f4-254d-45d6-8ea5-793b27290235@email.android.com> <195857373.541921.1346440878117.JavaMail.root@zimbra.com> <01OJPE8YAE9M0006TF@mauve.mrochek.com> <50413296.7050808@flaska.net> <01OJPXELHPKK0006TF@mauve.mrochek.com> In-Reply-To: <01OJPXELHPKK0006TF@mauve.mrochek.com> Content-Type: text/plain; charset=iso-8859-1; format=flowed Subject: Re: [imapext] Problem with reusing untagged COPYUID in pipelined UID MOVE or MOVE 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, 04 Sep 2012 21:17:23 -0000 On 09/01/2012 04:24 AM, Ned Freed wrote: > First, there's nothing in the section that excludes UID commmands from its > restriction. Such an interpretation might make sense if UID commands were > introduced in a different document, but that's rather obviously not the > case. When I wrote text, I noticed that the UID MOVE status could be arguable. "a UID MOVE 123 foo" is legal even if 123 does not exist, but if the client does not know whether 123 exists at the time the command is sent to the server, then the command could be said to be is ambiguous, and 5.5 prohibits ambiguous commands. IMO ambiguous means something else: It means that the server cannot determine exactly what to do based on its parsing of the command. By this reading, the command above is legal, and UID MOVE can often be pipelined with other commands. Arnt From arnt@gulbrandsen.priv.no Tue Sep 4 14:17: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 E121421E8092 for ; Tue, 4 Sep 2012 14:17:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.065 X-Spam-Level: X-Spam-Status: No, score=-2.065 tagged_above=-999 required=5 tests=[AWL=0.535, 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 iXMdKy5R7ril for ; Tue, 4 Sep 2012 14:17:25 -0700 (PDT) Received: from strange.aox.org (strange.aox.org [IPv6:2001:4d88:100c::1]) by ietfa.amsl.com (Postfix) with ESMTP id BF27921E8040 for ; Tue, 4 Sep 2012 14:17:24 -0700 (PDT) Received: from fri.gulbrandsen.priv.no (unknown [127.0.0.1]) by strange.aox.org (Postfix) with ESMTP id 3637FF8FC3A; Tue, 4 Sep 2012 21:17:24 +0000 (UTC) Received: from arnt@gulbrandsen.priv.no by fri.gulbrandsen.priv.no (Archiveopteryx 3.1.4) with esmtpsa id 1346793443-29695-29694/11/3; Tue, 4 Sep 2012 21:17:23 +0000 Message-Id: <504668DC.1090309@gulbrandsen.priv.no> Date: Tue, 4 Sep 2012 22:47:24 +0200 From: Arnt Gulbrandsen User-Agent: Mozilla/5.0 (X11; Linux i686; rv:15.0) Gecko/20120827 Thunderbird/15.0 Mime-Version: 1.0 To: imapext@ietf.org References: <5040D39D.1000207@flaska.net> <703929f4-254d-45d6-8ea5-793b27290235@email.android.com> <195857373.541921.1346440878117.JavaMail.root@zimbra.com> <01OJPE8YAE9M0006TF@mauve.mrochek.com> <50413296.7050808@flaska.net> <01OJPXELHPKK0006TF@mauve.mrochek.com> <01OJSIC77SSK0006TF@mauve.mrochek.com> In-Reply-To: <01OJSIC77SSK0006TF@mauve.mrochek.com> Content-Type: text/plain; charset=iso-8859-1; format=flowed Subject: Re: [imapext] Problem with reusing untagged COPYUID in pipelined UID MOVE or MOVE 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, 04 Sep 2012 21:17:26 -0000 On 09/03/2012 04:19 AM, Ned Freed wrote: > Agreed. That said, if there's a real use-case for pipelining overlapped > MOVEs and the cost of addressing the issue is low, I don't object to > following that path either. I want move to be implementable in clients like this: if ( move supported ) { uid move } else { uid copy uid store uid expunge } The case for making the top branch pipelinable is that the bottom branch is (well, to the degree it is). That's also why I defined move in the terms I did. Arnt From arnt@gulbrandsen.priv.no Tue Sep 4 14:17:26 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 4354021E8040 for ; Tue, 4 Sep 2012 14:17:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.797 X-Spam-Level: X-Spam-Status: No, score=-1.797 tagged_above=-999 required=5 tests=[AWL=-0.267, BAYES_00=-2.599, DATE_IN_PAST_06_12=1.069] 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 aBcr7xxksdOX for ; Tue, 4 Sep 2012 14:17:25 -0700 (PDT) Received: from strange.aox.org (strange.aox.org [IPv6:2001:4d88:100c::1]) by ietfa.amsl.com (Postfix) with ESMTP id 746DA21E8083 for ; Tue, 4 Sep 2012 14:17:22 -0700 (PDT) Received: from fri.gulbrandsen.priv.no (unknown [127.0.0.1]) by strange.aox.org (Postfix) with ESMTP id 11318F8FC35; Tue, 4 Sep 2012 21:17:21 +0000 (UTC) Received: from arnt@gulbrandsen.priv.no by fri.gulbrandsen.priv.no (Archiveopteryx 3.1.4) with esmtpsa id 1346793440-29695-29694/11/1; Tue, 4 Sep 2012 21:17:20 +0000 Message-Id: <5045D01D.6020507@gulbrandsen.priv.no> Date: Tue, 4 Sep 2012 11:55:41 +0200 From: Arnt Gulbrandsen User-Agent: Mozilla/5.0 (X11; Linux i686; rv:15.0) Gecko/20120827 Thunderbird/15.0 Mime-Version: 1.0 To: imapext@ietf.org References: <5040D39D.1000207@flaska.net> <703929f4-254d-45d6-8ea5-793b27290235@email.android.com> <195857373.541921.1346440878117.JavaMail.root@zimbra.com> <01OJPE8YAE9M0006TF@mauve.mrochek.com> <7C514DB2-4787-437B-9B37-8A863E079CC1@iki.fi> In-Reply-To: <7C514DB2-4787-437B-9B37-8A863E079CC1@iki.fi> Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Subject: Re: [imapext] Problem with reusing untagged COPYUID in pipelined UID MOVE or MOVE 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, 04 Sep 2012 21:17:26 -0000 On 08/31/2012 11:09 PM, Timo Sirainen wrote: > It's definitely not obvious that 5.5 applies in this case, and I = wouldn't really even agree that it does apply (for MOVE yes, for UID = MOVE I think not). But if it's explicitly mentioned I guess that's = fine.. The other possibility would be to do it similar to ESEARCH = replies and include the tag (as in Jan's suggestion, although it would = need to be done differently). With editor hat off: I disagree. Adding another response code only helps in an odd case, and when it does=20 help, all it helps with is with cache hit ratio. I'm not sure it does=20 even that: How often does the user retrieve the just-moved messages, and=20 how much local storage is available for caching? In this csae, and with=20 editor firmly off, I think we're better off with a simpler spec than a=20 larger client cache. There is a certain tendency among us (myself included, I am sad to say)=20 to solve the problems we identify, without stopping to think whether the=20 additional complexity is really warranted. Arnt From arnt@gulbrandsen.priv.no Tue Sep 4 14:17:28 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 9EA1C21E809C for ; Tue, 4 Sep 2012 14:17:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.243 X-Spam-Level: X-Spam-Status: No, score=-2.243 tagged_above=-999 required=5 tests=[AWL=0.356, 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 Xu7h-+2jqeRl for ; Tue, 4 Sep 2012 14:17:27 -0700 (PDT) Received: from strange.aox.org (strange.aox.org [IPv6:2001:4d88:100c::1]) by ietfa.amsl.com (Postfix) with ESMTP id 909B921E8083 for ; Tue, 4 Sep 2012 14:17:26 -0700 (PDT) Received: from fri.gulbrandsen.priv.no (unknown [127.0.0.1]) by strange.aox.org (Postfix) with ESMTP id 0ABF5F8FC35; Tue, 4 Sep 2012 21:17:26 +0000 (UTC) Received: from arnt@gulbrandsen.priv.no by fri.gulbrandsen.priv.no (Archiveopteryx 3.1.4) with esmtpsa id 1346793445-29695-29694/11/4; Tue, 4 Sep 2012 21:17:25 +0000 Message-Id: <504669F7.3070709@gulbrandsen.priv.no> Date: Tue, 4 Sep 2012 22:52:07 +0200 From: Arnt Gulbrandsen User-Agent: Mozilla/5.0 (X11; Linux i686; rv:15.0) Gecko/20120827 Thunderbird/15.0 Mime-Version: 1.0 To: imapext@ietf.org References: <5040D39D.1000207@flaska.net> <703929f4-254d-45d6-8ea5-793b27290235@email.android.com> <195857373.541921.1346440878117.JavaMail.root@zimbra.com> <01OJPE8YAE9M0006TF@mauve.mrochek.com> <50413296.7050808@flaska.net> <01OJPXELHPKK0006TF@mauve.mrochek.com> In-Reply-To: <01OJPXELHPKK0006TF@mauve.mrochek.com> Content-Type: text/plain; charset=iso-8859-1; format=flowed Subject: Re: [imapext] Problem with reusing untagged COPYUID in pipelined UID MOVE or MOVE 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, 04 Sep 2012 21:17:28 -0000 On 09/01/2012 04:24 AM, Ned Freed wrote: > Doesn't follow. If the semantics and capabilities of a COPY/STORE/EXPUNGE > sequence were identical to MOVE, there would be no need for MOVE. As I understand it, MOVE exists mostly to stop complaints about having to handle errors part-way through. If a three-command sequence could be made to have the semantics and capabilities of a single command, IMAP would be such a different protocols that it might also cook breakfast for you. Arnt From arnt@gulbrandsen.priv.no Tue Sep 4 14:17: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 F139321E80A5 for ; Tue, 4 Sep 2012 14:17:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.332 X-Spam-Level: X-Spam-Status: No, score=-2.332 tagged_above=-999 required=5 tests=[AWL=0.267, 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 sLtHseTvUpUB for ; Tue, 4 Sep 2012 14:17:28 -0700 (PDT) Received: from strange.aox.org (strange.aox.org [IPv6:2001:4d88:100c::1]) by ietfa.amsl.com (Postfix) with ESMTP id BD52321E809D for ; Tue, 4 Sep 2012 14:17:27 -0700 (PDT) Received: from fri.gulbrandsen.priv.no (unknown [127.0.0.1]) by strange.aox.org (Postfix) with ESMTP id 2EAE6F8FC3A; Tue, 4 Sep 2012 21:17:27 +0000 (UTC) Received: from arnt@gulbrandsen.priv.no by fri.gulbrandsen.priv.no (Archiveopteryx 3.1.4) with esmtpsa id 1346793446-29695-29694/11/5; Tue, 4 Sep 2012 21:17:26 +0000 Message-Id: <50466F8A.3030602@gulbrandsen.priv.no> Date: Tue, 4 Sep 2012 23:15:54 +0200 From: Arnt Gulbrandsen User-Agent: Mozilla/5.0 (X11; Linux i686; rv:15.0) Gecko/20120827 Thunderbird/15.0 Mime-Version: 1.0 To: imapext@ietf.org References: <5040D39D.1000207@flaska.net> <703929f4-254d-45d6-8ea5-793b27290235@email.android.com> <195857373.541921.1346440878117.JavaMail.root@zimbra.com> <01OJPE8YAE9M0006TF@mauve.mrochek.com> <50413296.7050808@flaska.net> <01OJPXELHPKK0006TF@mauve.mrochek.com> In-Reply-To: Content-Type: text/plain; charset=iso-8859-1; format=flowed Subject: Re: [imapext] Problem with reusing untagged COPYUID in pipelined UID MOVE or MOVE 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, 04 Sep 2012 21:17:29 -0000 On 09/01/2012 05:29 PM, Barry Leiba wrote: > I think this is a very important comment, and I think it leads to something: > Let me strongly suggest that this document*downplay* the COPY + STORE > + EXPUNGE aspect, and focus on the actual result. ... > We're stuck in the > COPY + STORE + EXPUNGE mindset because it's the way we used to do > things, Uh, I wrote it that was explicitly because I want MOVE to be a slot-in replacement in existing client code and want emphasize its equivalence. Do you think this is a valuable property? > - I would re-word the second paragraph of Section 3 to talk about the > result of the command, NOT in terms of COPY + STORE + EXPUNGE. Doable, I suppose, but I have a feeling that either the document emphasizes the result and leaves readers to infer the equivalence, or it emphasizes the equivalence and leaves readers to infer the result. I know what I prefer, but my preference is that of a random WG participant. The editor will bow to majority opinion. > - I would re-word the penultimate paragraph of Section 3 to put it in > terms of COPY only; I don't think it's necessary to go beyond that > here. I rewrote entirely. It was a rotten paragraph. > - I would re-word Section 4.2 to this: In section 4, you suggest using simpler sentences than I wrote, but occasionally they sound normative. Would you (as AD) prefer simpler sentences with normative language over ones that clearly only point out what the rules in other RFC are? > 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. > > (And you need a normative reference to 4314 (yes, you do).) I made the reference normative. I don't see why though, could you explain? > - I would re-word the first paragraph of Section 4.3 to this: > > Servers supporting UIDPLUS [RFC4315] MUST send COPYUID > in response to a UID MOVE command. In this case you even suggest an upper-case MUST. Do you think section 4 ought to become normative? > - The second Section 4.3 needs to be renumbered to 4.4, and I would > re-word that this way: > > 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. OK. Arnt From jkt@flaska.net Wed Sep 5 02:35: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 8871321F8629 for ; Wed, 5 Sep 2012 02:35:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.95 X-Spam-Level: X-Spam-Status: No, score=-0.95 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kmCnWjxD4QPZ for ; Wed, 5 Sep 2012 02:35:31 -0700 (PDT) Received: from ipo2-out.fzu.cz (ipo2-out.fzu.cz [147.231.27.21]) by ietfa.amsl.com (Postfix) with ESMTP id 9087221F8628 for ; Wed, 5 Sep 2012 02:35:29 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiUDAN0bR1CT5xpZgWdsb2JhbAA7CoYFtRciAQEWJieCIAEBBAEjDwEFQAYLCxgCAgUTAwsCAgkDAgECAUUTCAEBiAMGBKc2kwyBIYoACgaDRoIKgRIDlVmBFJFrgVcI X-IronPort-AV: E=Sophos;i="4.80,372,1344204000"; d="scan'208";a="329615" Received: from freja.fzu.cz ([147.231.26.89]) by ipo2-out.fzu.cz with ESMTP; 05 Sep 2012 11:35:27 +0200 Received: from svist.flaska.net (ip-89-176-26-68.net.upcbroadband.cz [89.176.26.68]) by freja.fzu.cz (Postfix) with ESMTPSA id 7C36F3DA82 for ; Wed, 5 Sep 2012 11:35:27 +0200 (CEST) Message-ID: <50471CBC.4080009@flaska.net> Date: Wed, 05 Sep 2012 11:34:52 +0200 From: =?UTF-8?B?SmFuIEt1bmRyw6F0?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:9.0) Gecko/20120128 Thunderbird/9.0 MIME-Version: 1.0 To: imapext@ietf.org References: <5040D39D.1000207@flaska.net> <703929f4-254d-45d6-8ea5-793b27290235@email.android.com> <195857373.541921.1346440878117.JavaMail.root@zimbra.com> <01OJPE8YAE9M0006TF@mauve.mrochek.com> <7C514DB2-4787-437B-9B37-8A863E079CC1@iki.fi> <5045D01D.6020507@gulbrandsen.priv.no> In-Reply-To: <5045D01D.6020507@gulbrandsen.priv.no> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [imapext] Problem with reusing untagged COPYUID in pipelined UID MOVE or MOVE 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, 05 Sep 2012 09:35:32 -0000 On 09/04/12 11:55, Arnt Gulbrandsen wrote: > Adding another response code only helps in an odd case, and when it does > help, all it helps with is with cache hit ratio. I'm not sure it does > even that: How often does the user retrieve the just-moved messages, and > how much local storage is available for caching? In this csae, and with > editor firmly off, I think we're better off with a simpler spec than a > larger client cache. The whole point of the COPYUID is to help with the cache hit ratio. If that was not a goal worth making some work, there would be no reason for UIDPLUS' COPYUID to exist. We are already making a change in the COPYUID's semantics by moving it from a tagged response to an untagged one. This change brings along a loss of information; data which were previously implicitly available by the virtue of the tagged response are now missing. If the client wants to use the COPYUID response in its intended way anyway, it will have to determine the missing data somehow. What I claim here is that this has a significant cost in clients which use asynchronous dispatch of commands. Unfortunately, it is not possible to both "implement UID MOVE" and "reuse COPYUID as-is" at the same time; we have established that earlier and this observation has led to the proposed untagged COPYUID. However, this fact alone means that the new form of COPYUID is different from the previous one (in UID COPY). We cannot assume that the existing clients will be able to process untagged COPYUID. > There is a certain tendency among us (myself included, I am sad to say) > to solve the problems we identify, without stopping to think whether the > additional complexity is really warranted. This would be an excellent point if the draft used COPYUID as-is. However, the proposed way is different than in basic UIDPLUS, so the change to accommodate a former problem has been made already. Why not make a second change to fix another issue which was identified early enough in the process? Yes, it has a cost. Is there any other client developer willing to implement UID MOVE here who might tell us which variant of the COPYUID/MOVEUID they would prefer to implement in their clients? With kind regards, Jan -- Trojita, a fast e-mail client -- http://trojita.flaska.net/ From barryleiba.mailing.lists@gmail.com Wed Sep 5 06:04: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 0371521F8550 for ; Wed, 5 Sep 2012 06:04:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.803 X-Spam-Level: X-Spam-Status: No, score=-102.803 tagged_above=-999 required=5 tests=[AWL=0.174, 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 ciRpcAG2yX2J for ; Wed, 5 Sep 2012 06:04:53 -0700 (PDT) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 252D921F854E for ; Wed, 5 Sep 2012 06:04:52 -0700 (PDT) Received: by lahm15 with SMTP id m15so371908lah.31 for ; Wed, 05 Sep 2012 06:04:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=1w9U5S/rlX3AStpt3na2GIRBzaN+aEg67x1U8+Hdesw=; b=c+sWxFdc2wgZuBS35uUglbW2nLd8Vw1hxwCuHNqRnX7duvxSBZfJ9ZO4cCgSSPdn6W bMLKTTo1JmXrC5piMAummFjFymFh69K5pnX/F/JxybSUzrXcd+P6W0RoSCSig7h49i4s ppSRBw4sX0V0WOwdzbCyQPPg/N3bbVjegmIJJU6B+yZ9UsByAJiE3IWLpGFQYg6BSzLR MB+dSxDvjnYKXdnx0tvkL6rdtx6cSfx6nnHhnIG6s5sQ3uMzvE0CSUqb3Uo0ZKfZ4jho 7+Ry6uGR9wFxGWhFVtLrqUwh2+QJavp1+KEq2c15B2EjE3oNLJsiZOn27581458xNet9 bB9g== MIME-Version: 1.0 Received: by 10.152.108.206 with SMTP id hm14mr4706067lab.53.1346850290591; Wed, 05 Sep 2012 06:04:50 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.112.91.33 with HTTP; Wed, 5 Sep 2012 06:04:50 -0700 (PDT) In-Reply-To: <50466F8A.3030602@gulbrandsen.priv.no> References: <5040D39D.1000207@flaska.net> <703929f4-254d-45d6-8ea5-793b27290235@email.android.com> <195857373.541921.1346440878117.JavaMail.root@zimbra.com> <01OJPE8YAE9M0006TF@mauve.mrochek.com> <50413296.7050808@flaska.net> <01OJPXELHPKK0006TF@mauve.mrochek.com> <50466F8A.3030602@gulbrandsen.priv.no> Date: Wed, 5 Sep 2012 09:04:50 -0400 X-Google-Sender-Auth: tddo9ak0Q9YRTWt5Axk-iR4D42I Message-ID: From: Barry Leiba To: Arnt Gulbrandsen Content-Type: text/plain; charset=ISO-8859-1 Cc: imapext@ietf.org Subject: Re: [imapext] Problem with reusing untagged COPYUID in pipelined UID MOVE or MOVE 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, 05 Sep 2012 13:04:54 -0000 >> Let me strongly suggest that this document*downplay* the COPY + STORE >> + EXPUNGE aspect, and focus on the actual result. > > ... > >> We're stuck in the >> COPY + STORE + EXPUNGE mindset because it's the way we used to do >> things, > > Uh, I wrote it that was explicitly because I want MOVE to be a slot-in > replacement in existing client code and want emphasize its equivalence. Do > you think this is a valuable property? I think what's valuable in a protocol spec is to say what has to happen in the protocol. What has to happen is some variant of "the message appears in the target mailbox with a new UID, and disappears from the source mailbox, in what the client perceives as an atomic operation." Then I think it's perfectly fine to say, as an informational note, that this is approximately equivalent to COPY + STORE + EXPUNGE, and that clients that are currently using a sequence like that to perform this function can switch to MOVE seamlessly, or whatever you want to say about it in that regard. That's what I mean by "downplay" (or "play down", if you prefer): I'm not talking about being "silent" about it, but not stressing, all over the document, that MOVE is *defined as* COPY + STORE + EXPUNGE. We only need to give non-normative implementation advice on this, and probably only once. But it's important that the normative specification of the protocol NOT specify implementation details. >> - I would re-word the penultimate paragraph of Section 3 to put it in >> terms of COPY only; I don't think it's necessary to go beyond that >> here. > > I rewrote entirely. It was a rotten paragraph. It happens, even in the best of families. > In section 4, you suggest using simpler sentences than I wrote, but > occasionally they sound normative. Would you (as AD) prefer simpler > sentences with normative language over ones that clearly only point out what > the rules in other RFC are? You know that we disagree on this, you and I; we should have the working group weigh in: I think that when you talk about how implementations of handle MOVE, you have to be normative. You can't say, for instance, that UIDPLUS implementations kinda-sorta-might-consider sending COPYUID -- if you expect COPYUID here, you have to make it a normative requirement that UIDPLUS implementations do this when they add support for MOVE. If you expect ACL implementations to do the right thing for MOVE with respect to which access controls they require, you have to make it normative. That's also why the UIDPLUS and ACL references have to be normative references: you're putting normative requirements on implementations of those specs when they choose to add MOVE support. > In this case you even suggest an upper-case MUST. Do you think section 4 > ought to become normative? I'll add to the above that specification language doesn't HAVE to say "MUST" in order to be normative. In the case of my suggestions, I think 2119 language is right for those spots. But there's lots of normative language in the spec that doesn't use 2119 words, too. Barry From arnt@gulbrandsen.priv.no Wed Sep 5 06:10: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 84EED21F8650 for ; Wed, 5 Sep 2012 06:10:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.776 X-Spam-Level: X-Spam-Status: No, score=-1.776 tagged_above=-999 required=5 tests=[AWL=-0.396, BAYES_00=-2.599, DATE_IN_PAST_24_48=1.219] 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 XsfjXho0dizJ for ; Wed, 5 Sep 2012 06:10:06 -0700 (PDT) Received: from strange.aox.org (strange.aox.org [IPv6:2001:4d88:100c::1]) by ietfa.amsl.com (Postfix) with ESMTP id 542BE21F8658 for ; Wed, 5 Sep 2012 06:10:05 -0700 (PDT) Received: from fri.gulbrandsen.priv.no (unknown [127.0.0.1]) by strange.aox.org (Postfix) with ESMTP id 33569F8FF39; Wed, 5 Sep 2012 13:10:04 +0000 (UTC) Received: from arnt@gulbrandsen.priv.no by fri.gulbrandsen.priv.no (Archiveopteryx 3.1.4) with esmtpsa id 1346850602-29695-29694/11/10; Wed, 5 Sep 2012 13:10:02 +0000 Message-Id: <5045C160.5020702@gulbrandsen.priv.no> Date: Tue, 4 Sep 2012 10:52:48 +0200 From: Arnt Gulbrandsen User-Agent: Mozilla/5.0 (X11; Linux i686; rv:15.0) Gecko/20120827 Thunderbird/15.0 Mime-Version: 1.0 To: imapext@ietf.org References: <5040D39D.1000207@flaska.net> <703929f4-254d-45d6-8ea5-793b27290235@email.android.com> <195857373.541921.1346440878117.JavaMail.root@zimbra.com> In-Reply-To: <195857373.541921.1346440878117.JavaMail.root@zimbra.com> Content-Type: text/plain; charset=iso-8859-1; format=flowed Subject: Re: [imapext] Problem with reusing untagged COPYUID in pipelined UID MOVE or MOVE 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, 05 Sep 2012 13:10:06 -0000 5.5 is a botch. This sentence specifies what happens in the situation Jan describes (where the client unknowingly sends ambiguous commands): If the server detects a possible ambiguity, it MUST execute commands to completion in the order given by the client. I take that as a misleading way of saying "the server may do whatever comes easiest, so long as it only executes commands, and doesn't actually contain code to detect ambiguities". But I agree with Ned: It would be good for the document to talk more about this. I didn't so far, because I don't want to write anything that could sound like a rule and be read to conflict with existing rules. I'm going through the document now and trying to fix these problems. I'll send this reply (well, when the plane lands) and only reply to other messages in the thread if anything warrants particular comment. Sorry about the late replies. Travel and more travel. Arnt From ned.freed@mrochek.com Sat Sep 8 10:01: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 D3A8521F8575 for ; Sat, 8 Sep 2012 10:01:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.469 X-Spam-Level: X-Spam-Status: No, score=-2.469 tagged_above=-999 required=5 tests=[AWL=0.130, 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 CbkDC4MtSQEm for ; Sat, 8 Sep 2012 10:01:57 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id 0D52321F8567 for ; Sat, 8 Sep 2012 10:01:57 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OK0C6KRB4W008IAT@mauve.mrochek.com> for imapext@ietf.org; Sat, 8 Sep 2012 09:56:55 -0700 (PDT) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OJFFFOH4280006TF@mauve.mrochek.com>; Sat, 8 Sep 2012 09:56:53 -0700 (PDT) Message-id: <01OK0C6JWWPY0006TF@mauve.mrochek.com> Date: Sat, 08 Sep 2012 09:50:46 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Tue, 04 Sep 2012 22:47:24 +0200" <504668DC.1090309@gulbrandsen.priv.no> MIME-version: 1.0 Content-type: TEXT/PLAIN; Format=flowed References: <5040D39D.1000207@flaska.net> <703929f4-254d-45d6-8ea5-793b27290235@email.android.com> <195857373.541921.1346440878117.JavaMail.root@zimbra.com> <01OJPE8YAE9M0006TF@mauve.mrochek.com> <50413296.7050808@flaska.net> <01OJPXELHPKK0006TF@mauve.mrochek.com> <01OJSIC77SSK0006TF@mauve.mrochek.com> <504668DC.1090309@gulbrandsen.priv.no> To: Arnt Gulbrandsen Cc: imapext@ietf.org Subject: Re: [imapext] Problem with reusing untagged COPYUID in pipelined UID MOVE or MOVE 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, 08 Sep 2012 17:01:58 -0000 > On 09/03/2012 04:19 AM, Ned Freed wrote: > > Agreed. That said, if there's a real use-case for pipelining overlapped > > MOVEs and the cost of addressing the issue is low, I don't object to > > following that path either. > I want move to be implementable in clients like this: > if ( move supported ) { > uid move > } else { > uid copy > uid store > uid expunge > } I think that's a fine goal, but the thing this sort of presentation ignores is response handling. Sure, you can get the same effect with the two sequences in most cases, but when something goes wonky the handling in the latter case is potentially a lot more difficult. Again, if there's no advantage to using MOVE there's no point in specifying it. And the advantage that accrues just from sending one versus three commands is insignificant IMO. And since there has to be an advantage for a specification to be useful, that then means it's possible this may result in clients that require MOVE. That's the balancing act involved any time we specify an extension to anything. > The case for making the top branch pipelinable is that the bottom branch > is (well, to the degree it is). Which I guess is an argument for making changes to disambiguify the overlapped pipelining case. Or not - remember we're talking about overlapped pipelining, not pipelining in general. Ned From ned.freed@mrochek.com Sat Sep 8 10:01:58 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 5B5E521F8567 for ; Sat, 8 Sep 2012 10:01:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.481 X-Spam-Level: X-Spam-Status: No, score=-2.481 tagged_above=-999 required=5 tests=[AWL=0.118, 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 twtFdEl7AUXN for ; Sat, 8 Sep 2012 10:01:58 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id A4A8721F8574 for ; Sat, 8 Sep 2012 10:01:57 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OK0C7LCFU8007MP0@mauve.mrochek.com> for imapext@ietf.org; Sat, 8 Sep 2012 09:57:44 -0700 (PDT) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OJFFFOH4280006TF@mauve.mrochek.com>; Sat, 8 Sep 2012 09:57:42 -0700 (PDT) Message-id: <01OK0C7K4RX40006TF@mauve.mrochek.com> Date: Sat, 08 Sep 2012 09:57:22 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Tue, 04 Sep 2012 22:52:07 +0200" <504669F7.3070709@gulbrandsen.priv.no> MIME-version: 1.0 Content-type: TEXT/PLAIN; Format=flowed References: <5040D39D.1000207@flaska.net> <703929f4-254d-45d6-8ea5-793b27290235@email.android.com> <195857373.541921.1346440878117.JavaMail.root@zimbra.com> <01OJPE8YAE9M0006TF@mauve.mrochek.com> <50413296.7050808@flaska.net> <01OJPXELHPKK0006TF@mauve.mrochek.com> <504669F7.3070709@gulbrandsen.priv.no> To: Arnt Gulbrandsen Cc: imapext@ietf.org Subject: Re: [imapext] Problem with reusing untagged COPYUID in pipelined UID MOVE or MOVE 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, 08 Sep 2012 17:01:58 -0000 > On 09/01/2012 04:24 AM, Ned Freed wrote: > > Doesn't follow. If the semantics and capabilities of a COPY/STORE/EXPUNGE > > sequence were identical to MOVE, there would be no need for MOVE. > As I understand it, MOVE exists mostly to stop complaints about having > to handle errors part-way through. If a three-command sequence could be > made to have the semantics and capabilities of a single command, IMAP > would be such a different protocols that it might also cook breakfast > for you. I'm for that - I could use a good breakfast right now ;-) Ned From brong@fastmail.fm Sat Sep 8 10:45: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 A7E2721F8567 for ; Sat, 8 Sep 2012 10:45:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4AYO0bvnQRtw for ; Sat, 8 Sep 2012 10:45:14 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) by ietfa.amsl.com (Postfix) with ESMTP id 09CCC21F8559 for ; Sat, 8 Sep 2012 10:45:13 -0700 (PDT) Received: from compute3.internal (compute3.nyi.mail.srv.osa [10.202.2.43]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id B4D4120717; Sat, 8 Sep 2012 13:45:12 -0400 (EDT) Received: from web6.nyi.mail.srv.osa ([10.202.2.216]) by compute3.internal (MEProxy); Sat, 08 Sep 2012 13:45:12 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=fastmail.fm; h= message-id:from:to:cc:mime-version:content-transfer-encoding :content-type:in-reply-to:references:subject:date; s=mesmtp; bh= Y+LB0MGAovqrh/2hvZ7zNPpFd2U=; b=o5PNyBpPRxJdXtXcnj5JuSYyv1VscrDq cEIOAJi4rR0PAcidOEwq48miL16Ethulaq3BrrL9aGDY5ofSydnPc7DJ4/0ouXYZ oluHnhmBORQePHGrcJ0Ht4amz418GTEeYg6Z+bQBnC7UGVifUf48Gb4QaOjNRnKb OtZOpN3CSPw= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=message-id:from:to:cc:mime-version :content-transfer-encoding:content-type:in-reply-to:references :subject:date; s=smtpout; bh=Y+LB0MGAovqrh/2hvZ7zNPpFd2U=; b=lRU LGeM9+xuphZEeUSFlldyjwulEKArRAE33dYi5X+C/kv0CU7AtGAahc1ylIls7MtS ZntrTOUoF6LR9w1XsE2BHaHFHjrH60e3I9To7hcrewygSqZsV8Rni+nqCKDyPocs Qy4npCwEkKiQ9Y8VRLIseJl8f91QbHSL9nrl3ItU= Received: by web6.nyi.mail.srv.osa (Postfix, from userid 99) id 7CDEB68366F; Sat, 8 Sep 2012 13:45:12 -0400 (EDT) Message-Id: <1347126312.27538.140661125308745.436458E3@webmail.messagingengine.com> X-Sasl-Enc: r65L12a6f9Ln9m2v6RQCJlVZy5B4cEXkbUdtdsWajub9 1347126312 From: Bron Gondwana To: Ned Freed , Arnt Gulbrandsen MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain X-Mailer: MessagingEngine.com Webmail Interface In-Reply-To: <01OK0C6JWWPY0006TF@mauve.mrochek.com> References: <5040D39D.1000207@flaska.net> <703929f4-254d-45d6-8ea5-793b27290235@email.android.com> <195857373.541921.1346440878117.JavaMail.root@zimbra.com> <01OJPE8YAE9M0006TF@mauve.mrochek.com> <50413296.7050808@flaska.net> <01OJPXELHPKK0006TF@mauve.mrochek.com> <01OJSIC77SSK0006TF@mauve.mrochek.com> <504668DC.1090309@gulbrandsen.priv.no> <01OK0C6JWWPY0006TF@mauve.mrochek.com> Date: Sat, 08 Sep 2012 19:45:12 +0200 Cc: imapext@ietf.org Subject: Re: [imapext] Problem with reusing untagged COPYUID in pipelined UID MOVE or MOVE 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, 08 Sep 2012 17:45:14 -0000 On Sat, Sep 8, 2012, at 06:50 PM, Ned Freed wrote: > Again, if there's no advantage to using MOVE there's no point in specifying it. > And the advantage that accrues just from sending one versus three commands > is insignificant IMO. The massive advantage we've already seen is that a "MOVE" can be performed while the user is over quota, whereas COPY/STORE/EXPUNGE can't without the server delaying the quota check until some theoretically later point. Besides, a client with even the slightest sense can't pipeline COPY/STORE/EXPUNGE. You'd have to be totally insane. The above "over quota on copy" case leads to you deleting the only copy of your messages if you pipelined all three commands. Bron. -- Bron Gondwana brong@fastmail.fm From jkt@flaska.net Sat Sep 8 10:46: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 C474621F8567 for ; Sat, 8 Sep 2012 10:46:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.65 X-Spam-Level: X-Spam-Status: No, score=-0.65 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, J_CHICKENPOX_74=0.6, 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 bK0MakMpIdan for ; Sat, 8 Sep 2012 10:46:03 -0700 (PDT) Received: from ipo2-out.fzu.cz (ipo2-out.fzu.cz [147.231.27.21]) by ietfa.amsl.com (Postfix) with ESMTP id BFC8521F8559 for ; Sat, 8 Sep 2012 10:46:02 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlcCAMWCS1CT5xpZgWdsb2JhbABFhge1SyIBARYmJ4IgAQEFIxVAEQsYAgIFEwMLAgIJAwIBAgFFEwgBAYgMBKgUkiGBIYoLAYJ9gg2BEgOVXYEUkXGBYQ X-IronPort-AV: E=Sophos;i="4.80,392,1344204000"; d="scan'208";a="352682" Received: from freja.fzu.cz ([147.231.26.89]) by ipo2-out.fzu.cz with ESMTP; 08 Sep 2012 19:46:01 +0200 Received: from svist.flaska.net (ip-89-176-26-68.net.upcbroadband.cz [89.176.26.68]) by freja.fzu.cz (Postfix) with ESMTPSA id C02263DA82 for ; Sat, 8 Sep 2012 19:46:00 +0200 (CEST) Message-ID: <504B8430.8090405@flaska.net> Date: Sat, 08 Sep 2012 19:45:20 +0200 From: =?UTF-8?B?SmFuIEt1bmRyw6F0?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:9.0) Gecko/20120128 Thunderbird/9.0 MIME-Version: 1.0 To: imapext@ietf.org References: <5040D39D.1000207@flaska.net> <703929f4-254d-45d6-8ea5-793b27290235@email.android.com> <195857373.541921.1346440878117.JavaMail.root@zimbra.com> <01OJPE8YAE9M0006TF@mauve.mrochek.com> <50413296.7050808@flaska.net> <01OJPXELHPKK0006TF@mauve.mrochek.com> <01OJSIC77SSK0006TF@mauve.mrochek.com> <504668DC.1090309@gulbrandsen.priv.no> <01OK0C6JWWPY0006TF@mauve.mrochek.com> In-Reply-To: <01OK0C6JWWPY0006TF@mauve.mrochek.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [imapext] Problem with reusing untagged COPYUID in pipelined UID MOVE or MOVE 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, 08 Sep 2012 17:46:03 -0000 On 09/08/12 18:50, Ned Freed wrote: > Which I guess is an argument for making changes to disambiguify the > overlapped > pipelining case. Or not - remember we're talking about overlapped > pipelining, > not pipelining in general. Actually there's still a problem when pipelining non-overlapping ranges which move to different mailboxes. Clients have to explicitly look up the untagged COPYUID to the respective UID MOVE command, which is suboptimal in my opinion. Assuming the servers are "reasonable" and return only those UIDs which were referenced in the UID MOVE command (which is something not mandated by either 4315, or by the current draft, AFAIK), the clients would work well enough with something like this: void handle_untagged_COPYUID(source_UIDs, ...): for each command in pending_commands if command.type == UID_MOVE: if (command.uid_range.contains(any_of(source_UIDs))): command.handle_COPYUID(source_UIDs, ...) Please note that a simple-minded check like "if (command.uid_range[0] == source_UIDs[0])" will fail when the first message fails to get copied (which is always possible when it got expunged from a concurrent session). The algorithm would also be much worse if servers were allowed to return UIDs which weren't requested by the corresponding UID MOVE. Could the draft clarify that this is forbidden? (An observation: if the COPYUID contained an explicit mailbox reference, servers would be able to send these to other concurrent sessions as well, for all of COPY/UID COPY/MOVE/UID MOVE commands. That's clearly outside the scope of this draft, very likely too late to be introduced now and -- I suspect -- it would also bring very negligible benefit in the real world (clients being disconnected etc), much smaller than the unofficial DIGEST proposals, but I still wanted to mention this. Just a random observation.) With kind regards, Jan -- Trojita, a fast e-mail client -- http://trojita.flaska.net/ From ned.freed@mrochek.com Sat Sep 8 11:07: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 61EDF21F84A6 for ; Sat, 8 Sep 2012 11:07:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.491 X-Spam-Level: X-Spam-Status: No, score=-2.491 tagged_above=-999 required=5 tests=[AWL=0.108, 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 9x4vfT5KG7HX for ; Sat, 8 Sep 2012 11:07:30 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id 8555B21F849D for ; Sat, 8 Sep 2012 11:07:30 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OK0EGUOP5C0086VQ@mauve.mrochek.com> for imapext@ietf.org; Sat, 8 Sep 2012 11:02:28 -0700 (PDT) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OJYUTAHY0W0006TG@mauve.mrochek.com>; Sat, 8 Sep 2012 11:02:25 -0700 (PDT) Message-id: <01OK0EGSR4I80006TG@mauve.mrochek.com> Date: Sat, 08 Sep 2012 11:01:30 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Sat, 08 Sep 2012 19:45:12 +0200" <1347126312.27538.140661125308745.436458E3@webmail.messagingengine.com> MIME-version: 1.0 Content-type: TEXT/PLAIN References: <5040D39D.1000207@flaska.net> <703929f4-254d-45d6-8ea5-793b27290235@email.android.com> <195857373.541921.1346440878117.JavaMail.root@zimbra.com> <01OJPE8YAE9M0006TF@mauve.mrochek.com> <50413296.7050808@flaska.net> <01OJPXELHPKK0006TF@mauve.mrochek.com> <01OJSIC77SSK0006TF@mauve.mrochek.com> <504668DC.1090309@gulbrandsen.priv.no> <01OK0C6JWWPY0006TF@mauve.mrochek.com> <1347126312.27538.140661125308745.436458E3@webmail.messagingengine.com> To: Bron Gondwana Cc: Arnt Gulbrandsen , Ned Freed , imapext@ietf.org Subject: Re: [imapext] Problem with reusing untagged COPYUID in pipelined UID MOVE or MOVE 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, 08 Sep 2012 18:07:31 -0000 > On Sat, Sep 8, 2012, at 06:50 PM, Ned Freed wrote: > > Again, if there's no advantage to using MOVE there's no point in specifying it. > > And the advantage that accrues just from sending one versus three commands > > is insignificant IMO. > The massive advantage we've already seen is that a "MOVE" can be performed > while the user is over quota, whereas COPY/STORE/EXPUNGE can't without the > server delaying the quota check until some theoretically later point. > Besides, a client with even the slightest sense can't pipeline > COPY/STORE/EXPUNGE. You'd have to be totally insane. The above > "over quota on copy" case leads to you deleting the only copy of > your messages if you pipelined all three commands. *Very* good point, thanks for making it. Ned From jkt@flaska.net Sat Sep 8 11:18:35 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 271C521F84E6 for ; Sat, 8 Sep 2012 11:18:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.8 X-Spam-Level: X-Spam-Status: No, score=-0.8 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1PHfAc-76N9W for ; Sat, 8 Sep 2012 11:18:34 -0700 (PDT) Received: from ipo2-out.fzu.cz (ipo2-out.fzu.cz [147.231.27.21]) by ietfa.amsl.com (Postfix) with ESMTP id 3E82221F84E4 for ; Sat, 8 Sep 2012 11:18:33 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlgCAM2KS1CT5xpZgWdsb2JhbABFhge1SxQOAQEWJieCHAQBAQUjFUARCxgCAgUTAwsCAgkDAgECAUUTCAEBhUWCKxwEqBeSJIEhigwCgnuCDYESA5VdgRSRcYFZCA X-IronPort-AV: E=Sophos;i="4.80,392,1344204000"; d="scan'208";a="352717" Received: from freja.fzu.cz ([147.231.26.89]) by ipo2-out.fzu.cz with ESMTP; 08 Sep 2012 20:18:32 +0200 Received: from svist.flaska.net (ip-89-176-26-68.net.upcbroadband.cz [89.176.26.68]) by freja.fzu.cz (Postfix) with ESMTPSA id BAF193DA82 for ; Sat, 8 Sep 2012 20:18:32 +0200 (CEST) Message-ID: <504B8BD7.7050300@flaska.net> Date: Sat, 08 Sep 2012 20:17:59 +0200 From: =?UTF-8?B?SmFuIEt1bmRyw6F0?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:9.0) Gecko/20120128 Thunderbird/9.0 MIME-Version: 1.0 To: imapext@ietf.org References: <5040D39D.1000207@flaska.net> <703929f4-254d-45d6-8ea5-793b27290235@email.android.com> <195857373.541921.1346440878117.JavaMail.root@zimbra.com> <01OJPE8YAE9M0006TF@mauve.mrochek.com> <50413296.7050808@flaska.net> <01OJPXELHPKK0006TF@mauve.mrochek.com> <01OJSIC77SSK0006TF@mauve.mrochek.com> <504668DC.1090309@gulbrandsen.priv.no> <01OK0C6JWWPY0006TF@mauve.mrochek.com> <1347126312.27538.140661125308745.436458E3@webmail.messagingengine.com> <01OK0EGSR4I80006TG@mauve.mrochek.com> In-Reply-To: <01OK0EGSR4I80006TG@mauve.mrochek.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [imapext] Problem with reusing untagged COPYUID in pipelined UID MOVE or MOVE 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, 08 Sep 2012 18:18:35 -0000 On 09/08/12 20:01, Ned Freed wrote: >> Besides, a client with even the slightest sense can't pipeline >> COPY/STORE/EXPUNGE. You'd have to be totally insane. The above >> "over quota on copy" case leads to you deleting the only copy of >> your messages if you pipelined all three commands. > > *Very* good point, thanks for making it. To prevent a possible misunderstanding -- while it is indeed insane to pipeline COPY/STORE/EXPUNGE *and* equally insane to pipeline their UID variants, there's no risk of data loss when pipelining the UID STORE and UID EXPUNGE tuple. It is also completely safe to pipeline independent "move operations", i.e. one does not have to wait for all three to finish before invoking the next UID COPY. These run in parallel just fine. I assume that all participants in this discussion are well aware of these facts, but I'd like to make this situation clear for other readers who might mistakenly interpret this subthread as "you cannot pipeline moves anyway, so what's the point?". Cheers, Jan -- Trojita, a fast e-mail client -- http://trojita.flaska.net/ From ned.freed@mrochek.com Sat Sep 8 11:20: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 8EE2421F84EF for ; Sat, 8 Sep 2012 11:20:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.049 X-Spam-Level: X-Spam-Status: No, score=-2.049 tagged_above=-999 required=5 tests=[AWL=-0.350, BAYES_00=-2.599, J_CHICKENPOX_74=0.6, 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 ZWJlBwWCAdFk for ; Sat, 8 Sep 2012 11:20:57 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id 7CD7821F84E6 for ; Sat, 8 Sep 2012 11:20:56 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OK0EVUBPSW0083XC@mauve.mrochek.com> for imapext@ietf.org; Sat, 8 Sep 2012 11:14:33 -0700 (PDT) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OJYUTAHY0W0006TG@mauve.mrochek.com>; Sat, 8 Sep 2012 11:14:31 -0700 (PDT) Message-id: <01OK0EVT8YY20006TG@mauve.mrochek.com> Date: Sat, 08 Sep 2012 11:09:04 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Sat, 08 Sep 2012 19:45:20 +0200" <504B8430.8090405@flaska.net> MIME-version: 1.0 Content-type: TEXT/PLAIN; Format=flowed References: <5040D39D.1000207@flaska.net> <703929f4-254d-45d6-8ea5-793b27290235@email.android.com> <195857373.541921.1346440878117.JavaMail.root@zimbra.com> <01OJPE8YAE9M0006TF@mauve.mrochek.com> <50413296.7050808@flaska.net> <01OJPXELHPKK0006TF@mauve.mrochek.com> <01OJSIC77SSK0006TF@mauve.mrochek.com> <504668DC.1090309@gulbrandsen.priv.no> <01OK0C6JWWPY0006TF@mauve.mrochek.com> <504B8430.8090405@flaska.net> To: =?UTF-8?B?SmFuIEt1bmRyw6F0?= Cc: imapext@ietf.org Subject: Re: [imapext] Problem with reusing untagged COPYUID in pipelined UID MOVE or MOVE 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, 08 Sep 2012 18:20:57 -0000 > On 09/08/12 18:50, Ned Freed wrote: > > Which I guess is an argument for making changes to disambiguify the > > overlapped > > pipelining case. Or not - remember we're talking about overlapped > > pipelining, > > not pipelining in general. > Actually there's still a problem when pipelining non-overlapping ranges > which move to different mailboxes. Clients have to explicitly look up > the untagged COPYUID to the respective UID MOVE command, which is > suboptimal in my opinion. > Assuming the servers are "reasonable" and return only those UIDs which > were referenced in the UID MOVE command (which is something not mandated > by either 4315, or by the current draft, AFAIK), the clients would work > well enough with something like this: > void handle_untagged_COPYUID(source_UIDs, ...): > for each command in pending_commands if command.type == UID_MOVE: > if (command.uid_range.contains(any_of(source_UIDs))): > command.handle_COPYUID(source_UIDs, ...) In other words, there's a reasonable way to handle it as long as nothing bizarre happens. > Please note that a simple-minded check like "if (command.uid_range[0] == > source_UIDs[0])" will fail when the first message fails to get copied > (which is always possible when it got expunged from a concurrent session). > The algorithm would also be much worse if servers were allowed to return > UIDs which weren't requested by the corresponding UID MOVE. Could the > draft clarify that this is forbidden? It had never occurred to me to imagine a case where a UID that wasn't specifically requested could be returned. I have trouble believing a server would do that, but if you really believe it could happen I don't have a problem with explicitly prohibiting it. That said, this sort of thing is in general a slippery slope. Specifications that attempt to expliitly outlaw every possible form of stupidity end up being unreadable and useless. (And yes, it's been tried, e.g. GOSIP.) Ned From brong@fastmail.fm Sun Sep 9 11:49: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 6276421F8550 for ; Sun, 9 Sep 2012 11:49:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.449 X-Spam-Level: X-Spam-Status: No, score=-3.449 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hrAIQkS02OFy for ; Sun, 9 Sep 2012 11:49:33 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) by ietfa.amsl.com (Postfix) with ESMTP id 9BF9521F84D5 for ; Sun, 9 Sep 2012 11:49:33 -0700 (PDT) Received: from compute4.internal (compute4.nyi.mail.srv.osa [10.202.2.44]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id 7C46B212CB; Sun, 9 Sep 2012 14:49:32 -0400 (EDT) Received: from web6.nyi.mail.srv.osa ([10.202.2.216]) by compute4.internal (MEProxy); Sun, 09 Sep 2012 14:49:32 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=fastmail.fm; h= message-id:from:to:cc:mime-version:content-transfer-encoding :content-type:subject:date:in-reply-to:references; s=mesmtp; bh= gWx5BnBpJlckX3FBxiquh9XVubQ=; b=JZscQyPVjuYeTuTwIYUxLhB+kuQlyjpm nCKfrRWbZtpK0ZHMeySNK7aYvMrKBcQ0SYuQ24OphYAz23nVwh79z8qjddIKjV5z 9JxKCIATo5x9jmkViAsT5AxCDjzQ9OB8FhWZ0wRhQW148ihr0PP8L4FSxmk9iKfY KDoXKOWJp00= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=message-id:from:to:cc:mime-version :content-transfer-encoding:content-type:subject:date:in-reply-to :references; s=smtpout; bh=gWx5BnBpJlckX3FBxiquh9XVubQ=; b=CMobW /xphTihw/FBVzkArSsC2xB3LU5ZcImzztd+nvcTcySgBUXgMyarxwK+pIeWDuCRa c8hU6kI05suCE6+ZFasR3IC+Z1rcxcVHd8ycHTx7EPIgfFSO/nsDkyJM9+IxlIOw g8aBJruiV/ODQZAnSSOB+RFgFfiTHBmLYnt0dk= Received: by web6.nyi.mail.srv.osa (Postfix, from userid 99) id 4793E683678; Sun, 9 Sep 2012 14:49:32 -0400 (EDT) Message-Id: <1347216572.827.140661125623869.12A8EB73@webmail.messagingengine.com> X-Sasl-Enc: USn99p890JtNXcp7KbuhDe7sTZvm8Vr5f20sA+RHxknu 1347216572 From: Bron Gondwana To: Ned Freed , =?ISO-8859-1?Q?Jan=20Kundr=E1t?= MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain X-Mailer: MessagingEngine.com Webmail Interface Date: Sun, 09 Sep 2012 20:49:32 +0200 In-Reply-To: <01OK0EVT8YY20006TG@mauve.mrochek.com> References: <5040D39D.1000207@flaska.net> <703929f4-254d-45d6-8ea5-793b27290235@email.android.com> <195857373.541921.1346440878117.JavaMail.root@zimbra.com> <01OJPE8YAE9M0006TF@mauve.mrochek.com> <50413296.7050808@flaska.net> <01OJPXELHPKK0006TF@mauve.mrochek.com> <01OJSIC77SSK0006TF@mauve.mrochek.com> <504668DC.1090309@gulbrandsen.priv.no> <01OK0C6JWWPY0006TF@mauve.mrochek.com> <504B8430.8090405@flaska.net> <01OK0EVT8YY20006TG@mauve.mrochek.com> Cc: imapext@ietf.org Subject: Re: [imapext] Problem with reusing untagged COPYUID in pipelined UID MOVE or MOVE 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: Sun, 09 Sep 2012 18:49:34 -0000 On Sat, Sep 8, 2012, at 08:09 PM, Ned Freed wrote: > That said, this sort of thing is in general a slippery slope. Specifications > that attempt to expliitly outlaw every possible form of stupidity end up being > unreadable and useless. (And yes, it's been tried, e.g. GOSIP.) My turn to say "an excellent point, thanks for making it"! I think Jan does have a point, that if your client is aggressively filing a pile of MOVE commands up the wire, it has to know what semantics to expect. If they are overlapping MOVE commands, I would argue that the client is plain wrong to be doing it an expecting a consistent result. It should block further changes being made to the UI element associated with the source UID until the server response has been received. If they're not overlapping, then the resulting COPYUID responses should be quite easily matchable to their sources. Even in the non-UID varient - you presumably know the UIDs before you sent the request, or any COPYUID, no matter how well annotated, will be useless for cache management. Yes, it's a bit of bookkeeping on the client side. You need to annotate each source UID with the destination folder - then when the associated COPYUID comes back, you can match them up. That annotation will also be handy for knowing that the message is "in transit", so you can't try moving it again! Bron. -- Bron Gondwana brong@fastmail.fm From barryleiba.mailing.lists@gmail.com Sun Sep 16 14:17:16 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 449E121F84B6 for ; Sun, 16 Sep 2012 14:17:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.658 X-Spam-Level: X-Spam-Status: No, score=-102.658 tagged_above=-999 required=5 tests=[AWL=-0.281, 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 fvDK9rumxNXL for ; Sun, 16 Sep 2012 14:17:15 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 1759A21F8455 for ; Sun, 16 Sep 2012 14:17:14 -0700 (PDT) Received: by lbky2 with SMTP id y2so4071886lbk.31 for ; Sun, 16 Sep 2012 14:17:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:content-type; bh=rDrmDHhmtk4rt2AFRca0wMlueMAJodUR4FhWdaqxFDA=; b=z6Yo3aUJiSAPN2k0qy3SEnsp+pJHxe9h8n/Wq2yA+R0ATp3cOVvhPJNB4Syt+hF9w1 vVLhh5WNo2tNly3mXld0//8Iuc9O+i3vC/cwZ/u0yS+IY++Vo6Rc7L1V5vQR/pVH2XOX JoAN/lJoSSjTMjgvH94kXDjYS2ROpphGYdv0JbcefiFXDsJJ+/hBexHgkKb13cL4wdPN kl/QH0hRBVJ+hTS7cmcxbYyrJAbnpvvVcWxk0miFcLLqCViHgHKt3JAnkpcszTBP5AlZ CByjhhl2dyfyyOIuiJI6807uQQLrsXdHJs0ZfRIoT45TQozdDeg/Iwr7CM3FfetxB9FN rHVQ== MIME-Version: 1.0 Received: by 10.112.31.233 with SMTP id d9mr3262332lbi.116.1347830233882; Sun, 16 Sep 2012 14:17:13 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.112.91.33 with HTTP; Sun, 16 Sep 2012 14:17:13 -0700 (PDT) Date: Sun, 16 Sep 2012 17:17:13 -0400 X-Google-Sender-Auth: oB35YesdskEPUOgauXG7NEVHA3c Message-ID: From: Barry Leiba To: imapext@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [imapext] Preparing for WGLC on IMAP MOVE: AD review 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: Sun, 16 Sep 2012 21:17:16 -0000 Because it looks like we're close to WGLC on the MOVE spec, I thought I would do an early AD review on it, so we can get any changes resulting from that into -02 and WGLC *that*. Consider what's below in addition to my earlier comments about de-emphasizing the COPY + STORE + EXPUNGE bit, and not making that the *definition* of MOVE (here: http://www.ietf.org/mail-archive/web/imapext/current/msg04694.html ). -- Abstract -- The abstract needs to stand alone and give a little bit of context, because people will just see the title and abstract sometimes. I suggest fixing the Overview as below, and then copying it verbatim into the Abstract. Also, please move the Abstract to be the first thing in the document, before the boilerplate. That matches the current I-D format. (It will also make it look less silly to have the Abstract and the Overview identical.) -- Overview -- First, please move this to be Section 1, and make the "conventions" section be either 1.1 or 2. The RFC Editor is likely to make that change anyway, and other reviewers will appreciate it. Then: OLD clients have to use a combination of UID STORE, UID COPY and EXPUNGE, and cope with partial failures and side effects. NEW clients have had to use a combination of UID STORE, UID COPY and EXPUNGE commands to create that function. This has meant needing to cope with partial failures and side effects. -- Section 3 -- RFC 3501 has a consistent way to define commands, and many of the extensions we write use that format. I would like to use it here, as well, to match up with the base IMAP spec. I suggest something like this: ---------- 3. MOVE and UID MOVE 3.1 MOVE Command Arguments: sequence set mailbox name Responses: no specific responses for this command Result: OK - move completed NO - move error: can't move those messages or to that name BAD - command unknown or arguments invalid 3.2 UID MOVE Command This extends the first form of the UID command (see [RFC3501], Section 6.4.8) to add the MOVE command, defined above, as a valid argument. 3.3 How They Work ... [Etc, as you have in Section 3 now, but see below.] ---------- With that up front, you can now word the explanation of how things work in terms of "MOVE", without having to say "UID MOVE" -- that was an artifact of having done just UID MOVE originally anyway. So, let's take this paragraph by paragraph: Paragraph 1: The MOVE command takes two arguments: a message set (sequence numbers for MOVE, UIDs for UID MOVE) and a named mailbox. Each message included in the set is moved, rather than copied, from the selected (source) mailbox to the named (target) mailbox. Paragraph 2: This means that a new message is created in the target mailbox, with a new UID, the original message is removed from the source mailbox, and it appears to the client as a single action. This has the same effect for each message as this sequence: 1. [UID] COPY 2. [UID] STORE +FLAGS.SILENT \DELETED 3. UID EXPUNGE Each message SHOULD either be moved or unaffected. The server MUST NOT leave a message in neither mailbox, and SHOULD NOT leave a message in both mailboxes afterwards, even if the server returns a tagged NO response. Paragraph 3: I suggest leaving all extension stuff for Section 4, and only say this here: Because of the similarity of MOVE to COPY, extensions that affect COPY affect MOVE in the same way. Response codes such TRYCREATE (see [RFC3501] Section 6.4.7), as well as those defined by extensions, are sent as appropriate. See Section 4 for more information about certain IMAP extensions. Paragraph 4 (the example): No change needed. Paragraph 5; I suggest a small clarification: Note that the server may send EXPUNGEs for other messages as well, if any happen to have been expunged at the same time; this is normal IMAP operation. Paragraph 6; I suggest a small clarification: Implementers will need to read [RFC4315] to understand what UID EXPUNGE does, though full implementation of [RFC4315] is not necessary. Paragraph 7: I can just about guarantee that this will get questions from some ADs, as it's currently worded. How about this?: Note that moving messages to the current mailbox (that is, where the source and target mailboxes are the same) is well-defined, so that MOVE is well defined for all the cases where COPY is. Paragraph 8: 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. -- Section 4 -- Add a new Section: 4.5. IMAP Events in Sieve MOVE applies to IMAP events in Sieve [reference] in the same way as COPY does. Therefore, MOVE can cause a Sieve script to be invoked with the imap.cause set to "COPY". 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". The [reference] for IMAP Events in Sieve is draft-ietf-sieve-imap-sieve-09, which should be in the RFC Editor queue any day now (so it won't hold this document up). -- Section 6 -- I suggest some more thought and some re-wording on the Security Considerations. I'd be surprised if this didn't get pushback from the Sec ADs as it is now. Alexey can probably help here. -- Barry, Responsible AD From ned.freed@mrochek.com Mon Sep 17 13:37:12 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 A663421F86E1 for ; Mon, 17 Sep 2012 13:37:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.219 X-Spam-Level: X-Spam-Status: No, score=-2.219 tagged_above=-999 required=5 tests=[AWL=-0.220, BAYES_00=-2.599, 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 OHBqEKLuPfRh for ; Mon, 17 Sep 2012 13:37:12 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id DB19621F86E3 for ; Mon, 17 Sep 2012 13:37:11 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OKD4BJNH8G00AC6Y@mauve.mrochek.com> for imapext@ietf.org; Mon, 17 Sep 2012 13:32:09 -0700 (PDT) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OJFFFOH4280006TF@mauve.mrochek.com>; Mon, 17 Sep 2012 13:32:07 -0700 (PDT) Message-id: <01OKD4BI9DLY0006TF@mauve.mrochek.com> Date: Mon, 17 Sep 2012 11:30:30 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Sun, 16 Sep 2012 17:17:13 -0400" MIME-version: 1.0 Content-type: TEXT/PLAIN References: To: Barry Leiba Cc: imapext@ietf.org Subject: Re: [imapext] Preparing for WGLC on IMAP MOVE: AD review 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, 17 Sep 2012 20:37:12 -0000 > Because it looks like we're close to WGLC on the MOVE spec, I thought > I would do an early AD review on it, so we can get any changes > resulting from that into -02 and WGLC *that*. Consider what's below > in addition to my earlier comments about de-emphasizing the COPY + > STORE + EXPUNGE bit, and not making that the *definition* of MOVE > (here: http://www.ietf.org/mail-archive/web/imapext/current/msg04694.html > ). > -- Abstract -- > The abstract needs to stand alone and give a little bit of context, > because people will just see the title and abstract sometimes. I hear this all the time and while it's certainly true for paywalled material I sometimes wonder how true it is for RFCs. But rules are rules, and your point is well taken that some changes are needed to conform. > I > suggest fixing the Overview as below, and then copying it verbatim > into the Abstract. Also, please move the Abstract to be the first > thing in the document, before the boilerplate. That matches the > current I-D format. (It will also make it look less silly to have the > Abstract and the Overview identical.) If I understand you correctly, this has the effect of changing the Abstract from: The MOVE extension provides commands to move one or more messages from the selected mailbox to a named mailbox. to: This document defines an IMAP extension to move messages from one mailbox to another. This function (very common in MUA UIs) is not provided by stock IMAP, and clients have to use a combination of UID STORE, UID COPY and EXPUNGE, and cope with partial failures and side effects. The one thing this loses that was there before is the idea that this is done with new commands. In IMAP this is important because a lot of extensions add stuff to existing commands. I would therefore suggest a change to something like: 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. This function (very common in MUA UIs) is not provided by stock IMAP, and clients have to use a combination of UID STORE, UID COPY and EXPUNGE, and cope with partial failures and side effects. > -- Overview -- > First, please move this to be Section 1, and make the "conventions" > section be either 1.1 or 2. The RFC Editor is likely to make that > change anyway, and other reviewers will appreciate it. > Then: > OLD > clients have to use a combination of UID > STORE, UID COPY and EXPUNGE, and cope with partial failures and side > effects. > NEW > clients have had to use a combination of UID > STORE, UID COPY and EXPUNGE commands to create that function. > This has meant needing to cope with partial failures and side effects. > -- Section 3 -- > RFC 3501 has a consistent way to define commands, and many of the > extensions we write use that format. I would like to use it here, as > well, to match up with the base IMAP spec. I suggest something like > this: > ---------- > 3. MOVE and UID MOVE > 3.1 MOVE Command > Arguments: sequence set > mailbox name > Responses: no specific responses for this command > Result: OK - move completed > NO - move error: can't move those messages or to that > name > BAD - command unknown or arguments invalid > 3.2 UID MOVE Command > This extends the first form of the UID command (see [RFC3501], Section > 6.4.8) to add the MOVE command, defined above, as a valid argument. > 3.3 How They Work > ... [Etc, as you have in Section 3 now, but see below.] > ---------- Sorry, I should have caught this one. I agree we should use this convention. > With that up front, you can now word the explanation of how things > work in terms of "MOVE", without having to say "UID MOVE" -- that was > an artifact of having done just UID MOVE originally anyway. So, let's > take this paragraph by paragraph: > ... These changes all look fine to me. > -- Section 4 -- > Add a new Section: > 4.5. IMAP Events in Sieve > MOVE applies to IMAP events in Sieve [reference] in the same way > as COPY does. Therefore, MOVE can cause a Sieve script to be > invoked with the imap.cause set to "COPY". 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 the right thing to do, but I have to ask: Given the timing of the Sieve in IMAP spec we could define a new "MOVE" cause in the base specification if we wanted to. Do we want to do this? > The [reference] for IMAP Events in Sieve is > draft-ietf-sieve-imap-sieve-09, which should be in the RFC Editor > queue any day now (so it won't hold this document up). > -- Section 6 -- > I suggest some more thought and some re-wording on the Security > Considerations. I'd be surprised if this didn't get pushback from the > Sec ADs as it is now. Alexey can probably help here. Is this the sort of thing you're looking for? MOVE does not introduce any new capabilities to IMAP, and this limits the security. However, the transactional semantics of MOVE may interact with specific implementations in ways that could have unexpected consequences. For example, moving messages between folders under the quota root may require temporary suspension of quota checking. An additional area of concern is interaction with antispam, antivirus, and other security scanning and auditing mechanisms. Different folders may have different security policies which could interact with MOVE in complex ways. Scanning with updated rules may also be required when messages are moved even with the underlying policy has not changed. Ned From barryleiba.mailing.lists@gmail.com Mon Sep 17 19:17:47 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 AFFBF21F8504 for ; Mon, 17 Sep 2012 19:17:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.656 X-Spam-Level: X-Spam-Status: No, score=-102.656 tagged_above=-999 required=5 tests=[AWL=-0.279, 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 2TXiS2rzcZtD for ; Mon, 17 Sep 2012 19:17:47 -0700 (PDT) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id A30F921F8413 for ; Mon, 17 Sep 2012 19:17:46 -0700 (PDT) Received: by lahm15 with SMTP id m15so4936134lah.31 for ; Mon, 17 Sep 2012 19:17:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=U+ib/oGFJaiPBRbHrMoOUHy4GS4pOi9UCUfJUmoKARg=; b=Z3SaC6yaTqP3lkHvK2AlrSCSW6wjSGs8VJ0xDVmTXKIyUsVo1vCjqHztKrvB1+z+Y7 cybV3lC75b6MolaN6pNs2f0qYl6NUF5/MmSPCV7VzRHB0KU+jgU6WLOdvioqOP3W6cPC 2frH0Z5rCAAjgWWPrvncyK6SxDA43BGtKMva7P+PnYtyOZCnKLIe7/eL3aq7eZ0iTFBz sol4hD2gJPGwHlRqyySy9y6ZtnAK1vBecRixLdUeT/NhbGJ4mDyebYVEX3Ts0GnmsAqs D3OTdmOgTOpG4GHfqr8xIs2Me+O6aBGbXmt+0GnCPglWIlsYYBx654IkRW2+RvxlsM2d kGyg== MIME-Version: 1.0 Received: by 10.112.84.101 with SMTP id x5mr4468603lby.28.1347934665357; Mon, 17 Sep 2012 19:17:45 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.112.91.33 with HTTP; Mon, 17 Sep 2012 19:17:45 -0700 (PDT) In-Reply-To: <01OKD4BI9DLY0006TF@mauve.mrochek.com> References: <01OKD4BI9DLY0006TF@mauve.mrochek.com> Date: Mon, 17 Sep 2012 22:17:45 -0400 X-Google-Sender-Auth: oz_rtr2iDyFPjG1sCq7yKzQZTAo Message-ID: From: Barry Leiba To: Ned Freed Content-Type: text/plain; charset=ISO-8859-1 Cc: imapext@ietf.org Subject: Re: [imapext] Preparing for WGLC on IMAP MOVE: AD review 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, 18 Sep 2012 02:17:47 -0000 >> -- Abstract -- >> The abstract needs to stand alone and give a little bit of context, >> because people will just see the title and abstract sometimes. > > I hear this all the time and while it's certainly true for paywalled material > I sometimes wonder how true it is for RFCs. But rules are rules, and your > point is well taken that some changes are needed to conform. Actually, the title and abstract are all that go out in the announcement message, and the RFC announcement list feeds other lists. It does have some value to have the RFC announcements have a useful abstract. Also, the RFC search features allow showing the abstract in the search response. You're right that it's not a big deal, and if it were a pain in the ass to conform or if there were a good reason not to, I'd be happy to push back on it. But as it's easy.... > The one thing this loses that was there before is the idea that this is done > with new commands. In IMAP this is important because a lot of extensions add > stuff to existing commands. I would therefore suggest a change to something > like: > > 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. > This function (very common in MUA UIs) is not provided by stock IMAP, and > clients have to use a combination of UID STORE, UID COPY and EXPUNGE, and > cope with partial failures and side effects. Yes, that's better; thanks. >> -- Section 4 -- > >> Add a new Section: > >> 4.5. IMAP Events in Sieve > >> MOVE applies to IMAP events in Sieve [reference] in the same way >> as COPY does. Therefore, MOVE can cause a Sieve script to be >> invoked with the imap.cause set to "COPY". 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 the right thing to do, but I have to ask: Given the timing > of the Sieve in IMAP spec we could define a new "MOVE" cause in the base > specification if we wanted to. Do we want to do this? I thought about that when I wrote the above, and I can't find a good reason to distinguish MOVE from COPY in imap-sieve. It also wouldn't be as simple as just defining a new cause: we'd have to decide whether only the target-mailbox script is run, or whether the source-mailbox script is run as well. My sense is that it's not an important distinction, and we don't want to go there. (I will note, though, that it makes a notable difference between copy/store/expunge and move: the former sequence causes a "flags" script to be run in the source mailbox, in addition to triggering a "copy" script to be run in the target mailbox. I'm proposing only the latter for move. But I'm just noting that here; again, I think that's beyond where we want to or should go.) >> -- Section 6 -- >> I suggest some more thought and some re-wording on the Security >> Considerations. I'd be surprised if this didn't get pushback from the >> Sec ADs as it is now. Alexey can probably help here. > > Is this the sort of thing you're looking for? > > MOVE does not introduce any new capabilities to IMAP, and this limits > the security. However, the transactional semantics of MOVE may > interact with specific implementations in ways that could have > unexpected consequences. For example, moving messages between folders > under the quota root may require temporary suspension of quota checking. > > An additional area of concern is interaction with antispam, antivirus, > and other security scanning and auditing mechanisms. Different folders > may have different security policies which could interact with MOVE > in complex ways. Scanning with updated rules may also be required > when messages are moved even with the underlying policy has not changed. Yes, I like that proposal (with fixing the first sentence to "limits the security effects", or some such). Arnt, there's a good starting point (and perhaps ending point as well). Barry From ned.freed@mrochek.com Mon Sep 17 19:36: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 3137221F8499 for ; Mon, 17 Sep 2012 19:36:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.21 X-Spam-Level: X-Spam-Status: No, score=-2.21 tagged_above=-999 required=5 tests=[AWL=-0.211, BAYES_00=-2.599, 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 gb6wF6RbDHw3 for ; Mon, 17 Sep 2012 19:36:20 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id BC77F21F847D for ; Mon, 17 Sep 2012 19:36:20 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OKDGUSW5N4009R8K@mauve.mrochek.com> for imapext@ietf.org; Mon, 17 Sep 2012 19:31:17 -0700 (PDT) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OJFFFOH4280006TF@mauve.mrochek.com>; Mon, 17 Sep 2012 19:31:14 -0700 (PDT) Message-id: <01OKDGUQZK520006TF@mauve.mrochek.com> Date: Mon, 17 Sep 2012 19:29:06 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Mon, 17 Sep 2012 22:17:45 -0400" MIME-version: 1.0 Content-type: TEXT/PLAIN References: <01OKD4BI9DLY0006TF@mauve.mrochek.com> To: Barry Leiba Cc: Ned Freed , imapext@ietf.org Subject: Re: [imapext] Preparing for WGLC on IMAP MOVE: AD review 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, 18 Sep 2012 02:36:21 -0000 > >> -- Section 4 -- > > > >> Add a new Section: > > > >> 4.5. IMAP Events in Sieve > > > >> MOVE applies to IMAP events in Sieve [reference] in the same way > >> as COPY does. Therefore, MOVE can cause a Sieve script to be > >> invoked with the imap.cause set to "COPY". 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 the right thing to do, but I have to ask: Given the timing > > of the Sieve in IMAP spec we could define a new "MOVE" cause in the base > > specification if we wanted to. Do we want to do this? > I thought about that when I wrote the above, and I can't find a good > reason to distinguish MOVE from COPY in imap-sieve. Neither can I, but I thought I'd ask the list to see if anyone else disagrees. > It also wouldn't > be as simple as just defining a new cause: we'd have to decide whether > only the target-mailbox script is run, or whether the source-mailbox > script is run as well. My sense is that it's not an important > distinction, and we don't want to go there. > (I will note, though, that it makes a notable difference between > copy/store/expunge and move: the former sequence causes a "flags" > script to be run in the source mailbox, in addition to triggering a > "copy" script to be run in the target mailbox. I'm proposing only the > latter for move. But I'm just noting that here; again, I think that's > beyond where we want to or should go.) Certainly WFM. Ned From barryleiba.mailing.lists@gmail.com Mon Sep 24 17:32:40 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 3356B1F0CAD for ; Mon, 24 Sep 2012 17:32:40 -0700 (PDT) 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 V18-pDTXy6lO for ; Mon, 24 Sep 2012 17:32:39 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 05B131F0CAC for ; Mon, 24 Sep 2012 17:32:38 -0700 (PDT) Received: by lbok13 with SMTP id k13so1864642lbo.31 for ; Mon, 24 Sep 2012 17:32:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type; bh=9+pvMGtRRNC9XdbRwyFBIuvqnG2zR6uFK4RGYb9m+m8=; b=txWuEy2wt1PwdaSCVbCIHBcyIJArJPDpfdXsLTxZ6pPVfPfa6OW88kEi/isaxLIPQr gbCZsDZ/+s6wrSafPLqKjOFfa/Y8b5ymke05mJR310FmmdwDxo0bXm7cLOHtHezBUSx2 K8/Y7XlOu1NqQ+eahcPzOdlRYejLEZGlfERBZIX5PU+yCRfEJb/Pw/JwLSl102z+/GqV OFEoeTR7PSFcsD3Qc+XCPYj3YF4Yr1M4o+eBHjmHlHGo/7Dbg7HpqfEXcGIATD33V2Og o2XfLUM94vGBWNRY3j7HjlHDrMcTkSsckzS6vQgpFWHHcgnJpoq0l1Th/MEA5uflAO4O 1uNw== MIME-Version: 1.0 Received: by 10.112.42.103 with SMTP id n7mr4943000lbl.69.1348533157636; Mon, 24 Sep 2012 17:32:37 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.112.91.33 with HTTP; Mon, 24 Sep 2012 17:32:37 -0700 (PDT) In-Reply-To: References: Date: Mon, 24 Sep 2012 20:32:37 -0400 X-Google-Sender-Auth: 0xPdo3UWAFw_-roaVql5F9mhbcM Message-ID: From: Barry Leiba To: imapext@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [imapext] Preparing for WGLC on IMAP MOVE: AD review 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, 25 Sep 2012 00:32:40 -0000 Responses to this from anyone else (besides Ned)? Arnt? Bron? Jan? Timo? Dan? Should Arnt just roll in my two reviews, modulo Ned's responses, and we're ready to go? Or what? Barry On Sun, Sep 16, 2012 at 5:17 PM, Barry Leiba wrote: > Because it looks like we're close to WGLC on the MOVE spec, I thought > I would do an early AD review on it, so we can get any changes > resulting from that into -02 and WGLC *that*. Consider what's below > in addition to my earlier comments about de-emphasizing the COPY + > STORE + EXPUNGE bit, and not making that the *definition* of MOVE > (here: http://www.ietf.org/mail-archive/web/imapext/current/msg04694.html > ). > > -- Abstract -- > The abstract needs to stand alone and give a little bit of context, > because people will just see the title and abstract sometimes. I > suggest fixing the Overview as below, and then copying it verbatim > into the Abstract. Also, please move the Abstract to be the first > thing in the document, before the boilerplate. That matches the > current I-D format. (It will also make it look less silly to have the > Abstract and the Overview identical.) > > -- Overview -- > First, please move this to be Section 1, and make the "conventions" > section be either 1.1 or 2. The RFC Editor is likely to make that > change anyway, and other reviewers will appreciate it. > > Then: > OLD > clients have to use a combination of UID > STORE, UID COPY and EXPUNGE, and cope with partial failures and side > effects. > NEW > clients have had to use a combination of UID > STORE, UID COPY and EXPUNGE commands to create that function. > This has meant needing to cope with partial failures and side effects. > > -- Section 3 -- > RFC 3501 has a consistent way to define commands, and many of the > extensions we write use that format. I would like to use it here, as > well, to match up with the base IMAP spec. I suggest something like > this: > > ---------- > 3. MOVE and UID MOVE > > 3.1 MOVE Command > > Arguments: sequence set > mailbox name > > Responses: no specific responses for this command > > Result: OK - move completed > NO - move error: can't move those messages or to that > name > BAD - command unknown or arguments invalid > > 3.2 UID MOVE Command > > This extends the first form of the UID command (see [RFC3501], Section > 6.4.8) to add the MOVE command, defined above, as a valid argument. > > 3.3 How They Work > > ... [Etc, as you have in Section 3 now, but see below.] > ---------- > > With that up front, you can now word the explanation of how things > work in terms of "MOVE", without having to say "UID MOVE" -- that was > an artifact of having done just UID MOVE originally anyway. So, let's > take this paragraph by paragraph: > > Paragraph 1: > > The MOVE command takes two arguments: a message set (sequence > numbers for MOVE, UIDs for UID MOVE) and a named mailbox. Each > message included in the set is moved, rather than copied, from > the selected (source) mailbox to the named (target) mailbox. > > Paragraph 2: > > This means that a new message is created in the target mailbox, > with a new UID, the original message is removed from the source > mailbox, and it appears to the client as a single action. This > has the same effect for each message as this sequence: > 1. [UID] COPY > 2. [UID] STORE +FLAGS.SILENT \DELETED > 3. UID EXPUNGE > Each message SHOULD either be moved or unaffected. The server > MUST NOT leave a message in neither mailbox, and SHOULD NOT > leave a message in both mailboxes afterwards, even if the server > returns a tagged NO response. > > Paragraph 3: > I suggest leaving all extension stuff for Section 4, and only say this here: > > Because of the similarity of MOVE to COPY, extensions that > affect COPY affect MOVE in the same way. Response codes such > TRYCREATE (see [RFC3501] Section 6.4.7), as well as those > defined by extensions, are sent as appropriate. See Section 4 > for more information about certain IMAP extensions. > > Paragraph 4 (the example): > No change needed. > > Paragraph 5; I suggest a small clarification: > > Note that the server may send EXPUNGEs for other messages as well, > if any happen to have been expunged at the same time; this is normal > IMAP operation. > > Paragraph 6; I suggest a small clarification: > > Implementers will need to read [RFC4315] to understand what UID > EXPUNGE does, though full implementation of [RFC4315] is not necessary. > > Paragraph 7: > I can just about guarantee that this will get questions from some ADs, > as it's currently worded. How about this?: > > Note that moving messages to the current mailbox (that is, where the > source and target mailboxes are the same) is well-defined, so that MOVE > is well defined for all the cases where COPY is. > > Paragraph 8: > > 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. > > -- Section 4 -- > > Add a new Section: > > 4.5. IMAP Events in Sieve > > MOVE applies to IMAP events in Sieve [reference] in the same way > as COPY does. Therefore, MOVE can cause a Sieve script to be > invoked with the imap.cause set to "COPY". 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". > > The [reference] for IMAP Events in Sieve is > draft-ietf-sieve-imap-sieve-09, which should be in the RFC Editor > queue any day now (so it won't hold this document up). > > -- Section 6 -- > I suggest some more thought and some re-wording on the Security > Considerations. I'd be surprised if this didn't get pushback from the > Sec ADs as it is now. Alexey can probably help here. > > -- > Barry, Responsible AD From adrien@qbik.com Mon Sep 24 17:38: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 3BE7C1F0CB0 for ; Mon, 24 Sep 2012 17:38:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=-4.300, BAYES_00=-2.599, 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 MTTis2vU7xUd for ; Mon, 24 Sep 2012 17:38:01 -0700 (PDT) Received: from smtp.qbik.com (smtp.qbik.com [210.55.214.35]) by ietfa.amsl.com (Postfix) with ESMTP id CE7F21F0CA8 for ; Mon, 24 Sep 2012 17:38:00 -0700 (PDT) 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 3458)) with SMTP id <0019263488@smtp.qbik.com>; Tue, 25 Sep 2012 12:37:58 +1200 From: "Adrien W. de Croy" To: "Barry Leiba" , "imapext@ietf.org" Date: Tue, 25 Sep 2012 00:37:58 +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 Subject: Re: [imapext] Preparing for WGLC on IMAP MOVE: AD review 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, 25 Sep 2012 00:38:02 -0000 =EF=BB=BF I don't have any concerns. We'll modify our implementation when it's=20 available, I think the only affected clients that I'm aware of don't=20 use the COPYUID response anyway. Regards Adrien ------ Original Message ------ From: "Barry Leiba" To: "imapext@ietf.org" Sent: 25/09/2012 12:32:37 p.m. Subject: Re: [imapext] Preparing for WGLC on IMAP MOVE: AD review >Responses to this from anyone else (besides Ned)? >Arnt? Bron? Jan? Timo? Dan? >Should Arnt just roll in my two reviews, modulo Ned's responses, and >we're ready to go? Or what? > >Barry > >On Sun, Sep 16, 2012 at 5:17 PM, Barry Leiba = wrote: > >> >>Because it looks like we're close to WGLC on the MOVE spec, I thought >>I would do an early AD review on it, so we can get any changes >>resulting from that into -02 and WGLC *that*. Consider what's below >>in addition to my earlier comments about de-emphasizing the COPY + >>STORE + EXPUNGE bit, and not making that the *definition* of MOVE >>(here: http://www.ietf.org/mail-archive/web/imapext/current/msg04694.html >>). >> >>-- Abstract -- >>The abstract needs to stand alone and give a little bit of context, >>because people will just see the title and abstract sometimes. I >>suggest fixing the Overview as below, and then copying it verbatim >>into the Abstract. Also, please move the Abstract to be the first >>thing in the document, before the boilerplate. That matches the >>current I-D format. (It will also make it look less silly to have the >>Abstract and the Overview identical.) >> >>-- Overview -- >>First, please move this to be Section 1, and make the "conventions" >>section be either 1.1 or 2. The RFC Editor is likely to make that >>change anyway, and other reviewers will appreciate it. >> >>Then: >>OLD >> clients have to use a combination of UID >> STORE, UID COPY and EXPUNGE, and cope with partial failures and side >> effects. >>NEW >> clients have had to use a combination of UID >> STORE, UID COPY and EXPUNGE commands to create that function. >> This has meant needing to cope with partial failures and side effects. >> >>-- Section 3 -- >>RFC 3501 has a consistent way to define commands, and many of the >>extensions we write use that format. I would like to use it here, as >>well, to match up with the base IMAP spec. I suggest something like >>this: >> >>---------- >>3. MOVE and UID MOVE >> >>3.1 MOVE Command >> >> Arguments: sequence set >> mailbox name >> >> Responses: no specific responses for this command >> >> Result: OK - move completed >> NO - move error: can't move those messages or to that >> name >> BAD - command unknown or arguments invalid >> >>3.2 UID MOVE Command >> >>This extends the first form of the UID command (see [RFC3501], Section >>6.4.8) to add the MOVE command, defined above, as a valid argument. >> >>3.3 How They Work >> >>... [Etc, as you have in Section 3 now, but see below.] >>---------- >> >>With that up front, you can now word the explanation of how things >>work in terms of "MOVE", without having to say "UID MOVE" -- that was >>an artifact of having done just UID MOVE originally anyway. So, let's >>take this paragraph by paragraph: >> >>Paragraph 1: >> >> The MOVE command takes two arguments: a message set (sequence >> numbers for MOVE, UIDs for UID MOVE) and a named mailbox. Each >> message included in the set is moved, rather than copied, from >> the selected (source) mailbox to the named (target) mailbox. >> >>Paragraph 2: >> >> This means that a new message is created in the target mailbox, >> with a new UID, the original message is removed from the source >> mailbox, and it appears to the client as a single action. This >> has the same effect for each message as this sequence: >> 1. [UID] COPY >> 2. [UID] STORE +FLAGS.SILENT \DELETED >> 3. UID EXPUNGE >> Each message SHOULD either be moved or unaffected. The server >> MUST NOT leave a message in neither mailbox, and SHOULD NOT >> leave a message in both mailboxes afterwards, even if the server >> returns a tagged NO response. >> >>Paragraph 3: >>I suggest leaving all extension stuff for Section 4, and only say this= here: >> >> Because of the similarity of MOVE to COPY, extensions that >> affect COPY affect MOVE in the same way. Response codes such >> TRYCREATE (see [RFC3501] Section 6.4.7), as well as those >> defined by extensions, are sent as appropriate. See Section 4 >> for more information about certain IMAP extensions. >> >>Paragraph 4 (the example): >>No change needed. >> >>Paragraph 5; I suggest a small clarification: >> >> Note that the server may send EXPUNGEs for other messages as well, >> if any happen to have been expunged at the same time; this is normal >> IMAP operation. >> >>Paragraph 6; I suggest a small clarification: >> >> Implementers will need to read [RFC4315] to understand what UID >> EXPUNGE does, though full implementation of [RFC4315] is not necessary= . >> >>Paragraph 7: >>I can just about guarantee that this will get questions from some ADs, >>as it's currently worded. How about this?: >> >> Note that moving messages to the current mailbox (that is, where the >> source and target mailboxes are the same) is well-defined, so that = MOVE >> is well defined for all the cases where COPY is. >> >>Paragraph 8: >> >> 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. >> >>-- Section 4 -- >> >>Add a new Section: >> >> 4.5. IMAP Events in Sieve >> >> MOVE applies to IMAP events in Sieve [reference] in the same way >> as COPY does. Therefore, MOVE can cause a Sieve script to be >> invoked with the imap.cause set to "COPY". 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". >> >>The [reference] for IMAP Events in Sieve is >>draft-ietf-sieve-imap-sieve-09, which should be in the RFC Editor >>queue any day now (so it won't hold this document up). >> >>-- Section 6 -- >>I suggest some more thought and some re-wording on the Security >>Considerations. I'd be surprised if this didn't get pushback from the >>Sec ADs as it is now. Alexey can probably help here. >> >>-- >>Barry, Responsible AD >> > >_______________________________________________ >imapext mailing list >imapext@ietf.org >https://www.ietf.org/mailman/listinfo/imapext > > From tss@iki.fi Mon Sep 24 17:49: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 55F9D1F0CA8 for ; Mon, 24 Sep 2012 17:49:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.15 X-Spam-Level: X-Spam-Status: No, score=-110.15 tagged_above=-999 required=5 tests=[AWL=-0.151, BAYES_00=-2.599, J_CHICKENPOX_45=0.6, 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 VB8YpkuyzT91 for ; Mon, 24 Sep 2012 17:49:43 -0700 (PDT) Received: from dovecot.org (dovecot.org [193.210.130.67]) by ietfa.amsl.com (Postfix) with ESMTP id 0DF9B1F0CB7 for ; Mon, 24 Sep 2012 17:49:43 -0700 (PDT) Received: from [192.168.10.101] (a88-112-255-76.elisa-laajakaista.fi [88.112.255.76]) by dovecot.org (Postfix) with ESMTP id 938EA1AE87C4; Tue, 25 Sep 2012 03:49:41 +0300 (EEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Timo Sirainen In-Reply-To: Date: Tue, 25 Sep 2012 03:49:36 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <84FD013A-A6F8-4846-B99C-813F1A5AD939@iki.fi> References: To: Barry Leiba X-Mailer: Apple Mail (2.1084) Cc: imapext@ietf.org Subject: Re: [imapext] Preparing for WGLC on IMAP MOVE: AD review 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, 25 Sep 2012 00:49:44 -0000 Sorry, busy :( But I read through this thread and I don't see any = problems. Security section might want to mention the possibility of deadlock if = the server works by locking both of the mailboxes. On 25.9.2012, at 3.32, Barry Leiba wrote: > Responses to this from anyone else (besides Ned)? > Arnt? Bron? Jan? Timo? Dan? > Should Arnt just roll in my two reviews, modulo Ned's responses, and > we're ready to go? Or what? >=20 > Barry >=20 > On Sun, Sep 16, 2012 at 5:17 PM, Barry Leiba = wrote: >> Because it looks like we're close to WGLC on the MOVE spec, I thought >> I would do an early AD review on it, so we can get any changes >> resulting from that into -02 and WGLC *that*. Consider what's below >> in addition to my earlier comments about de-emphasizing the COPY + >> STORE + EXPUNGE bit, and not making that the *definition* of MOVE >> (here: = http://www.ietf.org/mail-archive/web/imapext/current/msg04694.html >> ). >>=20 >> -- Abstract -- >> The abstract needs to stand alone and give a little bit of context, >> because people will just see the title and abstract sometimes. I >> suggest fixing the Overview as below, and then copying it verbatim >> into the Abstract. Also, please move the Abstract to be the first >> thing in the document, before the boilerplate. That matches the >> current I-D format. (It will also make it look less silly to have = the >> Abstract and the Overview identical.) >>=20 >> -- Overview -- >> First, please move this to be Section 1, and make the "conventions" >> section be either 1.1 or 2. The RFC Editor is likely to make that >> change anyway, and other reviewers will appreciate it. >>=20 >> Then: >> OLD >> clients have to use a combination of UID >> STORE, UID COPY and EXPUNGE, and cope with partial failures and = side >> effects. >> NEW >> clients have had to use a combination of UID >> STORE, UID COPY and EXPUNGE commands to create that function. >> This has meant needing to cope with partial failures and side = effects. >>=20 >> -- Section 3 -- >> RFC 3501 has a consistent way to define commands, and many of the >> extensions we write use that format. I would like to use it here, as >> well, to match up with the base IMAP spec. I suggest something like >> this: >>=20 >> ---------- >> 3. MOVE and UID MOVE >>=20 >> 3.1 MOVE Command >>=20 >> Arguments: sequence set >> mailbox name >>=20 >> Responses: no specific responses for this command >>=20 >> Result: OK - move completed >> NO - move error: can't move those messages or to that >> name >> BAD - command unknown or arguments invalid >>=20 >> 3.2 UID MOVE Command >>=20 >> This extends the first form of the UID command (see [RFC3501], = Section >> 6.4.8) to add the MOVE command, defined above, as a valid argument. >>=20 >> 3.3 How They Work >>=20 >> ... [Etc, as you have in Section 3 now, but see below.] >> ---------- >>=20 >> With that up front, you can now word the explanation of how things >> work in terms of "MOVE", without having to say "UID MOVE" -- that was >> an artifact of having done just UID MOVE originally anyway. So, = let's >> take this paragraph by paragraph: >>=20 >> Paragraph 1: >>=20 >> The MOVE command takes two arguments: a message set (sequence >> numbers for MOVE, UIDs for UID MOVE) and a named mailbox. Each >> message included in the set is moved, rather than copied, from >> the selected (source) mailbox to the named (target) mailbox. >>=20 >> Paragraph 2: >>=20 >> This means that a new message is created in the target mailbox, >> with a new UID, the original message is removed from the source >> mailbox, and it appears to the client as a single action. This >> has the same effect for each message as this sequence: >> 1. [UID] COPY >> 2. [UID] STORE +FLAGS.SILENT \DELETED >> 3. UID EXPUNGE >> Each message SHOULD either be moved or unaffected. The server >> MUST NOT leave a message in neither mailbox, and SHOULD NOT >> leave a message in both mailboxes afterwards, even if the server >> returns a tagged NO response. >>=20 >> Paragraph 3: >> I suggest leaving all extension stuff for Section 4, and only say = this here: >>=20 >> Because of the similarity of MOVE to COPY, extensions that >> affect COPY affect MOVE in the same way. Response codes such >> TRYCREATE (see [RFC3501] Section 6.4.7), as well as those >> defined by extensions, are sent as appropriate. See Section 4 >> for more information about certain IMAP extensions. >>=20 >> Paragraph 4 (the example): >> No change needed. >>=20 >> Paragraph 5; I suggest a small clarification: >>=20 >> Note that the server may send EXPUNGEs for other messages as well, >> if any happen to have been expunged at the same time; this is = normal >> IMAP operation. >>=20 >> Paragraph 6; I suggest a small clarification: >>=20 >> Implementers will need to read [RFC4315] to understand what UID >> EXPUNGE does, though full implementation of [RFC4315] is not = necessary. >>=20 >> Paragraph 7: >> I can just about guarantee that this will get questions from some = ADs, >> as it's currently worded. How about this?: >>=20 >> Note that moving messages to the current mailbox (that is, where = the >> source and target mailboxes are the same) is well-defined, so that = MOVE >> is well defined for all the cases where COPY is. >>=20 >> Paragraph 8: >>=20 >> 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. >>=20 >> -- Section 4 -- >>=20 >> Add a new Section: >>=20 >> 4.5. IMAP Events in Sieve >>=20 >> MOVE applies to IMAP events in Sieve [reference] in the same way >> as COPY does. Therefore, MOVE can cause a Sieve script to be >> invoked with the imap.cause set to "COPY". 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". >>=20 >> The [reference] for IMAP Events in Sieve is >> draft-ietf-sieve-imap-sieve-09, which should be in the RFC Editor >> queue any day now (so it won't hold this document up). >>=20 >> -- Section 6 -- >> I suggest some more thought and some re-wording on the Security >> Considerations. I'd be surprised if this didn't get pushback from = the >> Sec ADs as it is now. Alexey can probably help here. >>=20 >> -- >> Barry, Responsible AD > _______________________________________________ > imapext mailing list > imapext@ietf.org > https://www.ietf.org/mailman/listinfo/imapext >=20 From ned.freed@mrochek.com Mon Sep 24 18:06: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 018091F0CB6 for ; Mon, 24 Sep 2012 18:06:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.226 X-Spam-Level: X-Spam-Status: No, score=-2.226 tagged_above=-999 required=5 tests=[AWL=-0.227, BAYES_00=-2.599, 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 O6LwicJilhKH for ; Mon, 24 Sep 2012 18:06:05 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id 1EBFD1F0CA8 for ; Mon, 24 Sep 2012 18:06:05 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OKN5QCIZE8007NJ1@mauve.mrochek.com> for imapext@ietf.org; Mon, 24 Sep 2012 18:01:02 -0700 (PDT) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OJFFFOH4280006TF@mauve.mrochek.com>; Mon, 24 Sep 2012 18:00:59 -0700 (PDT) Message-id: <01OKN5QANWJ20006TF@mauve.mrochek.com> Date: Mon, 24 Sep 2012 17:58:08 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Tue, 25 Sep 2012 03:49:36 +0300" <84FD013A-A6F8-4846-B99C-813F1A5AD939@iki.fi> MIME-version: 1.0 Content-type: TEXT/PLAIN References: <84FD013A-A6F8-4846-B99C-813F1A5AD939@iki.fi> To: Timo Sirainen Cc: Barry Leiba , imapext@ietf.org Subject: Re: [imapext] Preparing for WGLC on IMAP MOVE: AD review 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, 25 Sep 2012 01:06:06 -0000 > Sorry, busy :( But I read through this thread and I don't see any problems. > Security section might want to mention the possibility of deadlock if the server works by locking both of the mailboxes. Not clear on what you're getting at here. If you're talking about someone doing a completely crap implementation that allows a deadlock condition to occur on completely legitimate operations, then that's an implementation detail, not a security consideration. OTOH, if there's a series of commands that can be sent to a carelessly done implementation that will cause a deadlock, then yes, that absolutely does need to be in the security considerations. Ned > On 25.9.2012, at 3.32, Barry Leiba wrote: > > Responses to this from anyone else (besides Ned)? > > Arnt? Bron? Jan? Timo? Dan? > > Should Arnt just roll in my two reviews, modulo Ned's responses, and > > we're ready to go? Or what? > > > > Barry > > > > On Sun, Sep 16, 2012 at 5:17 PM, Barry Leiba wrote: > >> Because it looks like we're close to WGLC on the MOVE spec, I thought > >> I would do an early AD review on it, so we can get any changes > >> resulting from that into -02 and WGLC *that*. Consider what's below > >> in addition to my earlier comments about de-emphasizing the COPY + > >> STORE + EXPUNGE bit, and not making that the *definition* of MOVE > >> (here: http://www.ietf.org/mail-archive/web/imapext/current/msg04694.html > >> ). > >> > >> -- Abstract -- > >> The abstract needs to stand alone and give a little bit of context, > >> because people will just see the title and abstract sometimes. I > >> suggest fixing the Overview as below, and then copying it verbatim > >> into the Abstract. Also, please move the Abstract to be the first > >> thing in the document, before the boilerplate. That matches the > >> current I-D format. (It will also make it look less silly to have the > >> Abstract and the Overview identical.) > >> > >> -- Overview -- > >> First, please move this to be Section 1, and make the "conventions" > >> section be either 1.1 or 2. The RFC Editor is likely to make that > >> change anyway, and other reviewers will appreciate it. > >> > >> Then: > >> OLD > >> clients have to use a combination of UID > >> STORE, UID COPY and EXPUNGE, and cope with partial failures and side > >> effects. > >> NEW > >> clients have had to use a combination of UID > >> STORE, UID COPY and EXPUNGE commands to create that function. > >> This has meant needing to cope with partial failures and side effects. > >> > >> -- Section 3 -- > >> RFC 3501 has a consistent way to define commands, and many of the > >> extensions we write use that format. I would like to use it here, as > >> well, to match up with the base IMAP spec. I suggest something like > >> this: > >> > >> ---------- > >> 3. MOVE and UID MOVE > >> > >> 3.1 MOVE Command > >> > >> Arguments: sequence set > >> mailbox name > >> > >> Responses: no specific responses for this command > >> > >> Result: OK - move completed > >> NO - move error: can't move those messages or to that > >> name > >> BAD - command unknown or arguments invalid > >> > >> 3.2 UID MOVE Command > >> > >> This extends the first form of the UID command (see [RFC3501], Section > >> 6.4.8) to add the MOVE command, defined above, as a valid argument. > >> > >> 3.3 How They Work > >> > >> ... [Etc, as you have in Section 3 now, but see below.] > >> ---------- > >> > >> With that up front, you can now word the explanation of how things > >> work in terms of "MOVE", without having to say "UID MOVE" -- that was > >> an artifact of having done just UID MOVE originally anyway. So, let's > >> take this paragraph by paragraph: > >> > >> Paragraph 1: > >> > >> The MOVE command takes two arguments: a message set (sequence > >> numbers for MOVE, UIDs for UID MOVE) and a named mailbox. Each > >> message included in the set is moved, rather than copied, from > >> the selected (source) mailbox to the named (target) mailbox. > >> > >> Paragraph 2: > >> > >> This means that a new message is created in the target mailbox, > >> with a new UID, the original message is removed from the source > >> mailbox, and it appears to the client as a single action. This > >> has the same effect for each message as this sequence: > >> 1. [UID] COPY > >> 2. [UID] STORE +FLAGS.SILENT \DELETED > >> 3. UID EXPUNGE > >> Each message SHOULD either be moved or unaffected. The server > >> MUST NOT leave a message in neither mailbox, and SHOULD NOT > >> leave a message in both mailboxes afterwards, even if the server > >> returns a tagged NO response. > >> > >> Paragraph 3: > >> I suggest leaving all extension stuff for Section 4, and only say this here: > >> > >> Because of the similarity of MOVE to COPY, extensions that > >> affect COPY affect MOVE in the same way. Response codes such > >> TRYCREATE (see [RFC3501] Section 6.4.7), as well as those > >> defined by extensions, are sent as appropriate. See Section 4 > >> for more information about certain IMAP extensions. > >> > >> Paragraph 4 (the example): > >> No change needed. > >> > >> Paragraph 5; I suggest a small clarification: > >> > >> Note that the server may send EXPUNGEs for other messages as well, > >> if any happen to have been expunged at the same time; this is normal > >> IMAP operation. > >> > >> Paragraph 6; I suggest a small clarification: > >> > >> Implementers will need to read [RFC4315] to understand what UID > >> EXPUNGE does, though full implementation of [RFC4315] is not necessary. > >> > >> Paragraph 7: > >> I can just about guarantee that this will get questions from some ADs, > >> as it's currently worded. How about this?: > >> > >> Note that moving messages to the current mailbox (that is, where the > >> source and target mailboxes are the same) is well-defined, so that MOVE > >> is well defined for all the cases where COPY is. > >> > >> Paragraph 8: > >> > >> 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. > >> > >> -- Section 4 -- > >> > >> Add a new Section: > >> > >> 4.5. IMAP Events in Sieve > >> > >> MOVE applies to IMAP events in Sieve [reference] in the same way > >> as COPY does. Therefore, MOVE can cause a Sieve script to be > >> invoked with the imap.cause set to "COPY". 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". > >> > >> The [reference] for IMAP Events in Sieve is > >> draft-ietf-sieve-imap-sieve-09, which should be in the RFC Editor > >> queue any day now (so it won't hold this document up). > >> > >> -- Section 6 -- > >> I suggest some more thought and some re-wording on the Security > >> Considerations. I'd be surprised if this didn't get pushback from the > >> Sec ADs as it is now. Alexey can probably help here. > >> > >> -- > >> Barry, Responsible AD > > _______________________________________________ > > imapext mailing list > > imapext@ietf.org > > https://www.ietf.org/mailman/listinfo/imapext > > > _______________________________________________ > imapext mailing list > imapext@ietf.org > https://www.ietf.org/mailman/listinfo/imapext From tss@iki.fi Mon Sep 24 18:24: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 4DB341F0CB0 for ; Mon, 24 Sep 2012 18:24:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.425 X-Spam-Level: X-Spam-Status: No, score=-110.425 tagged_above=-999 required=5 tests=[AWL=0.174, 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 cfbmA2UUbVw8 for ; Mon, 24 Sep 2012 18:24:19 -0700 (PDT) Received: from dovecot.org (dovecot.org [193.210.130.67]) by ietfa.amsl.com (Postfix) with ESMTP id B7B4F1F0CA8 for ; Mon, 24 Sep 2012 18:24:19 -0700 (PDT) Received: from [192.168.10.101] (a88-112-255-76.elisa-laajakaista.fi [88.112.255.76]) by dovecot.org (Postfix) with ESMTP id F03B91AE866A; Tue, 25 Sep 2012 04:24:17 +0300 (EEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Timo Sirainen In-Reply-To: <01OKN5QANWJ20006TF@mauve.mrochek.com> Date: Tue, 25 Sep 2012 04:24:17 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <84FD013A-A6F8-4846-B99C-813F1A5AD939@iki.fi> <01OKN5QANWJ20006TF@mauve.mrochek.com> To: Ned Freed X-Mailer: Apple Mail (2.1084) Cc: Barry Leiba , imapext@ietf.org Subject: Re: [imapext] Preparing for WGLC on IMAP MOVE: AD review 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, 25 Sep 2012 01:24:20 -0000 On 25.9.2012, at 3.58, Ned Freed wrote: >> Sorry, busy :( But I read through this thread and I don't see any = problems. >=20 >> Security section might want to mention the possibility of deadlock if = the server works by locking both of the mailboxes. >=20 > Not clear on what you're getting at here. If you're talking about = someone > doing a completely crap implementation that allows a deadlock = condition to > occur on completely legitimate operations, then that's an = implementation > detail, not a security consideration. OTOH, if there's a series of = commands > that can be sent to a carelessly done implementation that will cause a > deadlock, then yes, that absolutely does need to be in the security > considerations. MOVE is the only command in IMAP protocol that modifies two mailboxes at = the same time. So compared to all other commands it could require = special attention in some server implementations. Especially servers = that try to make MOVE fully atomic without a storage/database that does = row-level locking could easily deadlock (or detect it and fail).. From ned.freed@mrochek.com Mon Sep 24 18:50:43 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 04A081F0422 for ; Mon, 24 Sep 2012 18:50:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.519 X-Spam-Level: X-Spam-Status: No, score=-2.519 tagged_above=-999 required=5 tests=[AWL=0.080, 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 5iHN4ICY1ZKe for ; Mon, 24 Sep 2012 18:50:42 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id 20CAA21F8843 for ; Mon, 24 Sep 2012 18:50:41 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OKN6SVFXZK00ANXJ@mauve.mrochek.com> for imapext@ietf.org; Mon, 24 Sep 2012 18:31:19 -0700 (PDT) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OJFFFOH4280006TF@mauve.mrochek.com>; Mon, 24 Sep 2012 18:31:15 -0700 (PDT) Message-id: <01OKN6ST8UT40006TF@mauve.mrochek.com> Date: Mon, 24 Sep 2012 18:29:48 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Tue, 25 Sep 2012 04:24:17 +0300" MIME-version: 1.0 Content-type: TEXT/PLAIN References: <84FD013A-A6F8-4846-B99C-813F1A5AD939@iki.fi> <01OKN5QANWJ20006TF@mauve.mrochek.com> To: Timo Sirainen Cc: Barry Leiba , Ned Freed , imapext@ietf.org Subject: Re: [imapext] Preparing for WGLC on IMAP MOVE: AD review 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, 25 Sep 2012 01:50:43 -0000 > On 25.9.2012, at 3.58, Ned Freed wrote: > >> Sorry, busy :( But I read through this thread and I don't see any problems. > > > >> Security section might want to mention the possibility of deadlock if the server works by locking both of the mailboxes. > > > > Not clear on what you're getting at here. If you're talking about someone > > doing a completely crap implementation that allows a deadlock condition to > > occur on completely legitimate operations, then that's an implementation > > detail, not a security consideration. OTOH, if there's a series of commands > > that can be sent to a carelessly done implementation that will cause a > > deadlock, then yes, that absolutely does need to be in the security > > considerations. > MOVE is the only command in IMAP protocol that modifies two mailboxes at the > same time. So compared to all other commands it could require special attention > in some server implementations. Especially servers that try to make MOVE fully > atomic without a storage/database that does row-level locking could easily > deadlock (or detect it and fail).. I'm still thinking that's a implementation consideration, not a security consideration. An implementation that deadlocks is broken, not insecure. Ned From alexey.melnikov@isode.com Tue Sep 25 04:32: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 1491021F88CA for ; Tue, 25 Sep 2012 04:32:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.917 X-Spam-Level: X-Spam-Status: No, score=-101.917 tagged_above=-999 required=5 tests=[AWL=-0.310, BAYES_00=-2.599, DATE_IN_PAST_12_24=0.992, 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 VBNLKGLDyO7C for ; Tue, 25 Sep 2012 04:32:40 -0700 (PDT) Received: from statler.isode.com (statler.isode.com [62.3.217.254]) by ietfa.amsl.com (Postfix) with ESMTP id 27EB821F88AF for ; Tue, 25 Sep 2012 04:32:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1348572744; d=isode.com; s=selector; i=@isode.com; bh=GwvFEfkw4BIdNFcz+ljbFXE5lEWUiB8532ZD4I2M8Nw=; 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=kL0GcdcBXcxsTymaxhkY1+aXM23NorGVNc2h+n+bstyDDoweoaHSETg4+gbKFHLSaahLwu MGQZGaB6WCksoLnhF+fUXSX/qwXdyEwGPnMzYr3ft7Jjzb8pbn8XlaJFNJt5uFP7vX4tAU ErIEra6e4osF7u9ZXBt7fnqVuBObc/E=; Received: from [172.16.1.29] (shiny.isode.com [62.3.217.250]) by statler.isode.com (submission channel) via TCP with ESMTPA id ; Tue, 25 Sep 2012 12:32:23 +0100 Message-ID: <5060C0FC.8050005@isode.com> Date: Mon, 24 Sep 2012 21:22:20 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 To: Barry Leiba References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: imapext@ietf.org Subject: Re: [imapext] Preparing for WGLC on IMAP MOVE: AD review 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, 25 Sep 2012 11:32:41 -0000 Hi Barry, I am personally happy with all your other suggestions (and Ned's corrections/extra changes). One small thing: On 16/09/2012 22:17, Barry Leiba wrote: > Paragraph 7: > I can just about guarantee that this will get questions from some ADs, > as it's currently worded. How about this?: > > Note that moving messages to the current mailbox (that is, where the > source and target mailboxes are the same) is well-defined, so that MOVE > is well defined for all the cases where COPY is. Maybe it is me, but this still gets me very confused. This doesn't actually tell me anything useful. How about saying that "moving a message to the currently selected mailbox is allowed when copying the message to the currently selected mailbox is also allowed". Or something like that. From prvs=5615cf4909=zordogh@rim.com Tue Sep 25 12:22:01 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 3721B21F8870 for ; Tue, 25 Sep 2012 12:22:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.202 X-Spam-Level: X-Spam-Status: No, score=-5.202 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] 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 56L0AQuxKF5E for ; Tue, 25 Sep 2012 12:21:47 -0700 (PDT) Received: from mhs060cnc.rim.net (mhs060cnc.rim.net [208.65.73.34]) by ietfa.amsl.com (Postfix) with ESMTP id B651221F84E6 for ; Tue, 25 Sep 2012 12:21:46 -0700 (PDT) X-AuditID: 0a41282f-b7f196d0000008dc-b0-506204490867 Received: from XCT105CNC.rim.net (xct105cnc.rim.net [10.65.161.205]) by mhs060cnc.rim.net (SBG) with SMTP id C4.49.02268.94402605; Tue, 25 Sep 2012 14:21:45 -0500 (CDT) Received: from XCT109CNC.rim.net (10.65.161.209) by XCT105CNC.rim.net (10.65.161.205) with Microsoft SMTP Server (TLS) id 14.2.298.4; Tue, 25 Sep 2012 15:21:44 -0400 Received: from XMB163CNC.rim.net ([fe80::5805:6acc:b23a:e0a6]) by XCT109CNC.rim.net ([::1]) with mapi id 14.02.0318.001; Tue, 25 Sep 2012 15:21:44 -0400 From: Zoltan Ordogh To: "imapext@ietf.org" Thread-Topic: MOVE - A few late comments Thread-Index: Ac2bUv89gx2B1v8/TlWM3MMXzdiZvA== Date: Tue, 25 Sep 2012 19:21:44 +0000 Message-ID: <1DE983233DBBEB4A81F18FABD8208D762312F4F7@XMB163CNC.rim.net> Accept-Language: en-US, en-CA Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.160.245] Content-Type: multipart/alternative; boundary="_000_1DE983233DBBEB4A81F18FABD8208D762312F4F7XMB163CNCrimnet_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrCKsWRmVeSWpSXmKPExsXC5bjwrK4nS1KAwfqp/BaPZ3E5MHosWfKT KYAxqoHRJimxpCw4Mz1P384mMS8vvySxJFUhJbU42VbJJzU9MUchoCizLDG5UsElszg5JzEz N7VISSEzxVbJREmhICcxOTU3Na/EVimxoCA1L0XJjksBA9gAlWXmKaTmJeenZOal2yp5Bvvr WliYWuoaKtnpJnTyZLxa385eMHUtY8XCtZUNjH8mMXYxcnJICJhIfDz8iR3CFpO4cG89Wxcj F4eQwCpGib8TjjNCOCsZJab0nYLKzGGUuPH3MEsXIwcHm4CqxJyrsSDdIgKaEtc232ECsYUF lCW+Xr7CAhHXkHj/fw47hK0n0bSzGyzOAtT67/VTZhCbV8BD4svUyWC9jAKyEmvnrGQFsZkF xCVuPZnPBHGdgMSSPeeZIWxRiZeP/7FC2IoSq1/dYoOoz5f4+fAaC8RMQYmTM5+A2UICMhLP p1xin8AoMgvJ2FlIWmYhaYGI60gs2P2JDcLWlli28DUzjH3mwGMmZPEFjOyrGAVzM4oNzAyS 85L1ijJz9fJSSzYxgpOFhv4OxrfvLQ4xCnAwKvHwunxJDBBiTSwrrsw9xCjBwawkwmv8HCjE m5JYWZValB9fVJqTWnyI0RUYQhOZpbiT84GJLK8k3tjAADdHSZz31zmgIQLpwISVnZpakFoE M4eJgxNkD5eUSDEw7aQWJZaWZMSDkmN8MTA9SjUwprUdqdjRG97wlH+6enbu8aXa51hbNpmv XlkX6PqyYPey7W7h29KPsb1oquPY4RP73PfVBAa5JYnlvdd1vhvdfX/209RP7hEz15hPdtG9 Y6Jx62nGd4adMR9Wq8/8eO2S7Ean7WW1nqn50w1sPFeWaZlvrZs4T0Ts99ILc152+t9ZtCz/ 3D7Ok0osxRmJhlrMRcWJANSf/nNXAwAA Subject: [imapext] MOVE - A few late comments 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, 25 Sep 2012 19:22:01 -0000 --_000_1DE983233DBBEB4A81F18FABD8208D762312F4F7XMB163CNCrimnet_ Content-Type: text/plain; charset="us-ascii" content-transfer-encoding: quoted-printable Hi all, I might be a little late, I'll send it for your consideration anyway. Comments are prompt as I have to type it up quickly; let me know if it's not= verbose enough. General: There are a good deal of abbreviations that are not spelled out on their fir= st use (nor later on in the document). Section 1: "Formal syntax is defined by [RFC5234]." I guess what you mean to say is that the formal syntax is defined using the= ABNF notation defined in RFC5234. Section 2: "This document defines an IMAP extension to move messages from on= e mailbox to another." This document defines new IMAP commands to move messages? Section 2: "This function (very common in MUA UIs) is not provided by stock= IMAP ..." What is "stock imap"? One particular spec/product? Section 2: "and cope with partial failures and side effects" What side effects? If you have a reference that discusses those, add it. If= you don't, remove it. Section 3: "each message SHOULD either be moved or unaffected" I'd say MUST; there's no third option. Section 3: "The server SHOULD NOT leave a message in neither or both mailbox= es afterwards" I'd say MUST NOT; leave no room for fuzzy state. Section 3: " UID MOVE is the same as the three-command sequence in all other respects, which implies that extensions which affect the three- command sequence also affect UID MOVE, and that response codes such as COPYUID, TRYCREATE and so on should be sent as appropriate." Isn't there a less complicated way of saying this? For example: Since the UID MOVE command consist of three individual commands (COPY, STORE= , EXPUGE), it also triggers execution of the extensions (if any) to these co= mmands on the server-side. Consequently, the UID MOVE command returns respon= se codes of each command the their extensions (i.e. COPYUID, TRYCREATE, etc.= ). Section 3: "Implementers will need to read [RFC4315= ] to understand what UID EXPUNGE does. Implementing [RFC4315]= is not necessary." That sounds very awkward. Does it really make UIDPLUS a normative reference? Section 3: " Note that moving messages to the current mailbox is well-defined, so that MOVE is defined for all the cases where the COPY/STORE/EXPUNGE sequence is." This is not good enough, especially when ACLs are in use. Considering RFC4314 permissions: - COPY requires that I have 'r' right at the source and 'i' right at the= destination. - STORE requires that I have 't' right at the source. - EXPUNGE requires that I have 'e' right at the source. Consequently, I must have 'i' at the destination and 'r'+'t'+'e' at the sour= ce. Section 3: " The MOVE command performs the same actions UID MOVE. Notably, the server may send EXPUNGE (or VANISHED) messages before the tagged response, so the client cannot safely send more commands with MSN arguments while the server is processing MOVE." All right, but does it trigger extensions the same way UID MOVE does? Some extensions do not operate with UIDs. Also, a server implementation could translate MSNs to UIDs during execution= - which would trigger extensions hooked onto UID, too (even though MSNs wer= e used in the request). I.e. If UIDPLUS were to fire when MSNs were used in= the MOVE command, would that break the client? Any thoughts? Section 4. This is a nice idea, but not quite future-proof. Were all extensions (at least those that are found in RFCs) enumerated to da= te? Section 4.2: "it requires the same ACL rights as the union of those three commands" The union of three commands is a command-triplet, not access rights. I think what you want to say is that the UID MOVE requires that all permissi= ons that those three commands require if executed one-by-one. What about the MSN MOVE command? (this is clearly missing from this section) Section 5: "[RFC3501] defines the non-terminals "ca= pability", "command", "set" and "mailbox"." You might want to change "command" to "command-select" (or, add command-sele= ct). Section 5: " capability =3D/ "MOVE" command-select =3D/ ["UID "] "MOVE" SP set SP mailbox" RFC3501 does not define "set". Do you mean sequence-set? That's not good for= UIDs. I guess a new non-terminal to represent a message reference is in order? Any thoughts on this? reference =3D reference-type SP reference-value reference-type =3D "UID" / "SEQ" / "URLAUTH" / reference-type-ext reference-type-ext =3D atom ; It is not required that new reference types ; begin with "X-", see [XDASH] reference-value =3D uniqueid / \ ; see [IMAP] sequence-set / \ ; see [IMAP] authorized-url / \ ; see [URLAUTH] reference-value-ext authorized-url =3D authimapurlfull / \ ; see [URLAUTH] authimapurlrump ; see [URLAUTH] reference-value-ext =3D atom ; New reference values MUST correspond to ; reference-type-ext Section 6: " This document is believed to add no security problems." Provided that the server does verify that all required permissions are in pl= ace. Section 6: "Problems with these algorithms can lead to mail loss." You mean bad implementations of good algorithms, or just badly designed algo= rithms, right? Section 9: I'd think RFC4315 is not a normative reference; after all, one can always go= with MSNs. I guess it depends on how the MSN to UID translation turns out. Thank you for considering. --------------------------------------------------------------------- This transmission (including any attachments) may contain confidential infor= mation, privileged material (including material protected by the solicitor-c= lient or other applicable privileges), or constitute non-public information.= Any use of this information by anyone other than the intended recipient is= prohibited. If you have received this transmission in error, please immedia= tely reply to the sender and delete this information from your system. Use,= dissemination, distribution, or reproduction of this transmission by uninte= nded recipients is not authorized and may be unlawful. --_000_1DE983233DBBEB4A81F18FABD8208D762312F4F7XMB163CNCrimnet_ Content-Type: text/html; charset="us-ascii" content-transfer-encoding: quoted-printable

Hi all,

I might be a little late, I’ll send it for your= consideration anyway.

Comments are prompt as I have to type it up quickly;= let me know if it’s not verbose enough.

 

General:

There are a good deal of abbreviations that are not s= pelled out on their first use (nor later on in the document).

 

Section 1: “Formal syntax is defined by [RFC5234].”
I guess what you mean to say is that the formal syntax is defined using=
 the ABNF notation defined in RFC5234.

 

Section 2: “This document defines an IMAP extension to move messa=
ges from one mailbox to another.”
This document defines new IMAP commands to move messages?

 


Section 2: “This function (very common in MUA UIs) is not provide=
d by stock IMAP ...”


What is “stock imap”? One particular spec/product?


 


Section 2: “and cope with partial failures and side effects”=
;


What side effects? If you have a reference that discu=
sses those, add it. If you don’t, remove it.


 


Section 3: “each message SHOULD either be moved or unaffectedR=
21;


I’d say MUST; there’s no third option.


 


Section 3: “The server SHOULD NOT leave a message in neither or b=
oth mailboxes afterwards”


I’d say MUST NOT; leave no room for fuzzy state.


 


Section 3:


“   UID MOVE is the same as the three-command sequence=
 in all other


   respects, which implies that extensions which affect the t=
hree-


   command sequence also affect UID MOVE, and that response c=
odes such


   as COPYUID, TRYCREATE and so on should be sent as appropri=
ate.”


Isn’t there a less complicated way of saying this? For example:


Since the UID MOVE command consist of three individual commands (COPY,=
 STORE, EXPUGE), it also triggers execution of the extensions (if any) to th=
ese commands on the server-side. Consequently, the UID MOVE command returns=
 response codes of each command the their extensions (i.e. COPYUID, TRYCREAT=
E, etc.).


 


Section 3:


“Implementers will need to read [RFC4315] to understand what UID


   EXPUNGE does. Implementing [RFC4315] is not necessary.”


That sounds very awkward. Does it really make UIDPLUS a normative refer=
ence?


 


Section 3:


“   Note that moving messages to the current mailbox is=
 well-defined, so


   that MOVE is defined for all the cases where the COPY/STOR=
E/EXPUNGE


   sequence is.”


This is not good enough, especially when ACLs are in use.

Considering RFC4314 permissions:


-    COPY requires that I have ‘r’ right at the source and ‘i=
’ right at the destination.


-    STORE requires that I have ‘t’ right at the source.=



-    EXPUNGE requires that I have ‘e’ right at the source.


Consequently, I must have ‘i’ at the destination and ‘=
;r’+’t’+’e’ at the source.<=
/pre>

 


Section 3:


“   The MOVE command performs the same actions UID MOVE=
. Notably, the


   server may send EXPUNGE (or VANISHED) messages before the=
 tagged


   response, so the client cannot safely send more commands w=
ith MSN


   arguments while the server is processing MOVE.”=



All right, but does it trigger extensions the same way UID MOVE does?


Some extensions do not operate with UIDs.


Also, a server implementation could translate MSNs to UIDs during execu=
tion – which would trigger extensions hooked onto UID, too (even thoug=
h MSNs were used in the request). I.e. If UIDPLUS were to fire when MSNs wer=
e used in the MOVE command, would that break the client?


Any thoughts?


 


Section 4.


This is a nice idea, but not quite future-proof.


Were all extensions (at least those that are found in RFCs) enumerated=
 to date?


 


Section 4.2:


“it requires the same ACL rights as the union of those three comm=
ands”


The union of three commands is a command-triplet, not access rights.


I think what you want to say is that the UID MOVE requires that all per=
missions that those three commands require if executed one-by-one.


What about the MSN MOVE command? (this is clearly missing from this sec=
tion)


 


Section 5:


“[RFC3501] defines=
 the non-terminals "capability", "command", "set&qu=
ot; and "mailbox".”


You might want to change “command” to “command-select=
” (or, add command-select).


 


Section 5:


“     capability     =3D/=
 "MOVE"


      command-select =3D/ ["UID "] &=
quot;MOVE" SP set SP mailbox”


RFC3501 does not define “set”. Do you mean sequence-set? Th=
at’s not good for UIDs.


I guess a new non-terminal to represent a message reference is in order=
?


Any thoughts on this?


   reference        &=
nbsp;  =3D reference-type SP reference-value


   reference-type      =3D "UID=
" / "SEQ" / "URLAUTH" / reference-type-ext


   reference-type-ext  =3D atom


            =
;             ;=
 It is not required that new reference types


            =
;             ;=
 begin with "X-", see [XDASH]


   reference-value     =3D uniqueid / \&n=
bsp;        ; see [IMAP]


            =
;             se=
quence-set / \     ; see [IMAP]


            =
;             au=
thorized-url / \   ; see [URLAUTH]


            =
;             re=
ference-value-ext


   authorized-url      =3D authimapu=
rlfull / \  ; see [URLAUTH]


            =
;             au=
thimapurlrump      ; see [URLAUTH]


   reference-value-ext =3D atom


            =
;             ;=
 New reference values MUST correspond to


            =
;             ;=
 reference-type-ext


 


Section 6:


“   This document is believed to add no security proble=
ms.”


Provided that the server does verify that all required permissions are=
 in place.


 


Section 6:


“Problems with these algorithms can lead to mail loss.”


You mean bad implementations of good algorithms, or just badly designed=
 algorithms, right?


 


Section 9:


I’d think RFC4315 is not a normative=
 reference; after all, one can always go with MSNs.


I guess it depends on how the MSN to UID translation turns out. 


 


Thank you for considering.


 
---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential infor= mation, privileged material (including material protected by the solicitor-c= lient or other applicable privileges), or constitute non-public information.= Any use of this information by anyone other than the intended recipient is= prohibited. If you have received this transmission in error, please immedia= tely reply to the sender and delete this information from your system. Use,= dissemination, distribution, or reproduction of this transmission by uninte= nded recipients is not authorized and may be unlawful. --_000_1DE983233DBBEB4A81F18FABD8208D762312F4F7XMB163CNCrimnet_-- From brong@fastmail.fm Tue Sep 25 12:49: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 01C3B21F859F for ; Tue, 25 Sep 2012 12:49:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.224 X-Spam-Level: X-Spam-Status: No, score=-3.224 tagged_above=-999 required=5 tests=[AWL=-0.225, BAYES_00=-2.599, J_CHICKENPOX_53=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id voX00KbrC5Zm for ; Tue, 25 Sep 2012 12:49:49 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) by ietfa.amsl.com (Postfix) with ESMTP id E070A21F859B for ; Tue, 25 Sep 2012 12:49:48 -0700 (PDT) Received: from compute6.internal (compute6.nyi.mail.srv.osa [10.202.2.46]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id ED7F620978; Tue, 25 Sep 2012 15:49:47 -0400 (EDT) Received: from web6.nyi.mail.srv.osa ([10.202.2.216]) by compute6.internal (MEProxy); Tue, 25 Sep 2012 15:49:47 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=fastmail.fm; h= message-id:from:to:mime-version:content-transfer-encoding :content-type:in-reply-to:references:subject:date; s=mesmtp; bh= 4CWuJs1IAjIlVrMjf04IPkHBrh8=; b=CjskZAAwIHsELxmpiayx5qlnmUwixYiS GvThgUIUmpLTCqKzisbj2lpcdjLjTCcM3e/R0VhsEjUdxhSja7aurDaw9RNqVm87 R1hJ3WoCLqLRxg2xU2mAdbF/FL8YKw6XUChWkP3BTO2PXsP1S0WRO81jCTJZh8HY oW/FPeIUK5g= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=message-id:from:to:mime-version :content-transfer-encoding:content-type:in-reply-to:references :subject:date; s=smtpout; bh=4CWuJs1IAjIlVrMjf04IPkHBrh8=; b=fAF 9sWiWH3Gw+Y6N09Q14v/maLUeydR+TiSSGpb5C4vQtNiMjGu9wdl18s5vIERkV/4 y7NEEi0aD4ArSEkScBush6YVSoB4xwbtBLxloySuQtpAXx++uSGlayiXugW1BioZ qwvI6ftJE6O1UKpuXaCoFax3852nDXwHcLyu2EeQ= Received: by web6.nyi.mail.srv.osa (Postfix, from userid 99) id C35D1683699; Tue, 25 Sep 2012 15:49:47 -0400 (EDT) Message-Id: <1348602587.18365.140661132619417.766B1A99@webmail.messagingengine.com> X-Sasl-Enc: HfmfEe1x6yfdObVOSJJpwN+kvL9PlrQ1Xz3TatJzbWHL 1348602587 From: Bron Gondwana To: Zoltan Ordogh , "imapext@ietf.org" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain X-Mailer: MessagingEngine.com Webmail Interface In-Reply-To: <1DE983233DBBEB4A81F18FABD8208D762312F4F7@XMB163CNC.rim.net> References: <1DE983233DBBEB4A81F18FABD8208D762312F4F7@XMB163CNC.rim.net> Date: Tue, 25 Sep 2012 21:49:47 +0200 Subject: Re: [imapext] MOVE - A few late comments 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, 25 Sep 2012 19:49:50 -0000 On Tue, Sep 25, 2012, at 09:21 PM, Zoltan Ordogh wrote: > Section 2: "This document defines an IMAP extension to move messages from one mailbox to another." > > This document defines new IMAP commands to move messages? If it adds a CAPABILITY, it's an EXTENSION, right? > Section 2: "This function (very common in MUA UIs) is not provided by stock IMAP ..." > > What is "stock imap"? One particular spec/product? RFC3501 > Section 3: "each message SHOULD either be moved or unaffected" > > I'd say MUST; there's no third option. > > > > Section 3: "The server SHOULD NOT leave a message in neither or both mailboxes afterwards" > > I'd say MUST NOT; leave no room for fuzzy state. I can imagine failure modes on a server which doesn't have global transactional state where the message is committed to the destination mailbox but not yet removed from the source mailbox when something dies. Hence MUST NOT makes it significantly harder to implement. I'm happy with "MUST NOT leave a message neither mailbox, and SHOULD NOT leave a message in both mailboxes." > Section 3: > > " UID MOVE is the same as the three-command sequence in all other > respects, which implies that extensions which affect the three- > command sequence also affect UID MOVE, and that response codes such > as COPYUID, TRYCREATE and so on should be sent as appropriate." > > Isn't there a less complicated way of saying this? For example: > > Since the UID MOVE command consist of three individual commands (COPY, STORE, EXPUGE), it also triggers execution of the extensions (if any) to these commands on the server-side. Consequently, the UID MOVE command returns response codes of each command the their extensions (i.e. COPYUID, TRYCREATE, etc.). Now are you sure you've read all the discussion leading up to this? Because we've been leaning more the other way, de-emphasising the individual commands. I'm not sure that your wording is less complicated. That said, the original wording is pretty fuzzy, and contains a lower case "should". Perhaps this? "If the server supports extentions to COPY, STORE or EXPUNGE then it SHOULD apply those same extensions to MOVE and return the same responses (i.e. COPYUID, TRYCREATE, etc.) as if it was running the three-command sequence in order" > "Implementers will need to read [RFC4315] to understand what UID > EXPUNGE does. Implementing [RFC4315] is not necessary." > > That sounds very awkward. Does it really make UIDPLUS a normative reference? There's no non-UID version of EXPUNGE which allows you to expunge only a subset of messages. > " Note that moving messages to the current mailbox is well-defined, so > that MOVE is defined for all the cases where the COPY/STORE/EXPUNGE > sequence is." > > This is not good enough, especially when ACLs are in use. > > Considering RFC4314 permissions: > > - COPY requires that I have 'r' right at the source and 'i' right at the destination. > > - STORE requires that I have 't' right at the source. > > - EXPUNGE requires that I have 'e' right at the source. > > Consequently, I must have 'i' at the destination and 'r'+'t'+'e' at the source. Sorry, what's your problem here? If you don't have permissions, then the command fails with a permission denied response (possibly EEXIST if you don't even have rights to list the destination) And in this case, since source and destination are the same... "moving messages to the current mailbox" You obviously must have "irte" on the current mailbox to succeed. > Section 3: > > " The MOVE command performs the same actions UID MOVE. Notably, the > > server may send EXPUNGE (or VANISHED) messages before the tagged > > response, so the client cannot safely send more commands with MSN > > arguments while the server is processing MOVE." > > All right, but does it trigger extensions the same way UID MOVE does? > > Some extensions do not operate with UIDs. > > Also, a server implementation could translate MSNs to UIDs during execution - which would trigger extensions hooked onto UID, too (even though MSNs were used in the request). I.e. If UIDPLUS were to fire when MSNs were used in the MOVE command, would that break the client? > > Any thoughts? You have a point here. Hmm. . copy 1:2 inbox.sub . OK [COPYUID 1348602306 1:2 1:2] Completed Looks like I used MSNs and got a COPYUID response from Cyrus on my local testbed. We have all sorts of clients talk to our servers, and I've never seen a bug report that COPYUID confused any of them. Do you know any clients that would be confused? > Section 4.2: > > "it requires the same ACL rights as the union of those three commands" > > The union of three commands is a command-triplet, not access rights. > > I think what you want to say is that the UID MOVE requires that all permissions that those three commands require if executed one-by-one. > > What about the MSN MOVE command? (this is clearly missing from this section) Are there any MSN commands which require different ACLs than their UID equivalents? > Section 6: > > " This document is believed to add no security problems." > > Provided that the server does verify that all required permissions are in place. Well, yeah - duh. If you don't verify ACLs as specified in the other parts of the document, then you'll have a security problem. Bron. -- Bron Gondwana brong@fastmail.fm From tss@iki.fi Tue Sep 25 13:05: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 C52D41F0CE2 for ; Tue, 25 Sep 2012 13:05:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.15 X-Spam-Level: X-Spam-Status: No, score=-110.15 tagged_above=-999 required=5 tests=[AWL=-0.151, BAYES_00=-2.599, J_CHICKENPOX_53=0.6, 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 Hbq3s+3Kwp84 for ; Tue, 25 Sep 2012 13:05:54 -0700 (PDT) Received: from dovecot.org (dovecot.org [193.210.130.67]) by ietfa.amsl.com (Postfix) with ESMTP id 2FFDA1F0CDE for ; Tue, 25 Sep 2012 13:05:54 -0700 (PDT) Received: from [192.168.10.101] (a88-112-255-76.elisa-laajakaista.fi [88.112.255.76]) by dovecot.org (Postfix) with ESMTP id CBF251AE866A; Tue, 25 Sep 2012 23:05:52 +0300 (EEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Timo Sirainen In-Reply-To: <1348602587.18365.140661132619417.766B1A99@webmail.messagingengine.com> Date: Tue, 25 Sep 2012 23:05:52 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <9D7D7303-88DD-4B3B-89A2-AE5260ACDC29@iki.fi> References: <1DE983233DBBEB4A81F18FABD8208D762312F4F7@XMB163CNC.rim.net> <1348602587.18365.140661132619417.766B1A99@webmail.messagingengine.com> To: Bron Gondwana X-Mailer: Apple Mail (2.1084) Cc: Zoltan Ordogh , "imapext@ietf.org" Subject: Re: [imapext] MOVE - A few late comments 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, 25 Sep 2012 20:05:54 -0000 On 25.9.2012, at 22.49, Bron Gondwana wrote: >> Also, a server implementation could translate MSNs to UIDs during = execution - which would trigger extensions hooked onto UID, too (even = though MSNs were used in the request). I.e. If UIDPLUS were to fire when = MSNs were used in the MOVE command, would that break the client? >>=20 >> Any thoughts? >=20 > You have a point here. Hmm. >=20 > . copy 1:2 inbox.sub > . OK [COPYUID 1348602306 1:2 1:2] Completed >=20 > Looks like I used MSNs and got a COPYUID response from Cyrus on my > local testbed. We have all sorts of clients talk to our servers, > and I've never seen a bug report that COPYUID confused any of them. >=20 > Do you know any clients that would be confused? This works as specified by RFC 4315. There's no problem with sending = COPYUID response to non-UID COPY, and I don't think there should be any = problem with sending COPYUID response to non-UID MOVE. From jkt@flaska.net Wed Sep 26 00:12: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 0DEC821F867B for ; Wed, 26 Sep 2012 00:12:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.95 X-Spam-Level: X-Spam-Status: No, score=-0.95 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9WenpVBDyZYQ for ; Wed, 26 Sep 2012 00:12:40 -0700 (PDT) Received: from ipo2-out.fzu.cz (ipo2-out.fzu.cz [147.231.27.21]) by ietfa.amsl.com (Postfix) with ESMTP id 0CD1921F8471 for ; Wed, 26 Sep 2012 00:12:39 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqoCAPGpYlCT5xpZgWdsb2JhbABFhURHuVcjAQEWJieCIAEBBSNVEQsYCRYLAgIJAwIBAgFFEwgBAYgBpwOTEYs0gk+CDoESA45sgSCCKYMxgRWRfIFh X-IronPort-AV: E=Sophos;i="4.80,488,1344204000"; d="asc'?scan'208";a="470656" Received: from freja.fzu.cz ([147.231.26.89]) by ipo2-out.fzu.cz with ESMTP; 26 Sep 2012 09:12:36 +0200 Received: from svist.flaska.net (pc069c.fzu.cz [147.231.27.69]) by freja.fzu.cz (Postfix) with ESMTPSA id D64E33DA82 for ; Wed, 26 Sep 2012 09:12:36 +0200 (CEST) Message-ID: <5062AAC3.6010804@flaska.net> Date: Wed, 26 Sep 2012 09:12:03 +0200 From: =?UTF-8?B?SmFuIEt1bmRyw6F0?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: imapext@ietf.org References: <1DE983233DBBEB4A81F18FABD8208D762312F4F7@XMB163CNC.rim.net> <1348602587.18365.140661132619417.766B1A99@webmail.messagingengine.com> In-Reply-To: <1348602587.18365.140661132619417.766B1A99@webmail.messagingengine.com> X-Enigmail-Version: 1.4.3 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigA87A9BD4B191AC0116E7FF3F" Subject: Re: [imapext] MOVE - A few late comments 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, 26 Sep 2012 07:12:41 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigA87A9BD4B191AC0116E7FF3F Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 09/25/12 21:49, Bron Gondwana wrote: > "If the server supports extentions to COPY, STORE or EXPUNGE then it > SHOULD apply those same extensions to MOVE and return the same > responses (i.e. COPYUID, TRYCREATE, etc.) as if it was running the > three-command sequence in order" One should be very careful with the wording here, as saying "return the same responses" is not true in the current draft where the COPYUID response code is present in an untagged response -- that's different from RFC4315. With kind regards, Jan --=20 Trojita, a fast e-mail client -- http://trojita.flaska.net/ --------------enigA87A9BD4B191AC0116E7FF3F Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlBiqsMACgkQamXfqERyJRe8NgCggxmzU1qPJWPiElcbpwiDrt+s +KUAnRUU01ChOZ5oAycS0l7XvqcDE+6t =FTWH -----END PGP SIGNATURE----- --------------enigA87A9BD4B191AC0116E7FF3F-- From jkt@flaska.net Wed Sep 26 00:19:26 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 EFAEA21F87C5 for ; Wed, 26 Sep 2012 00:19:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.95 X-Spam-Level: X-Spam-Status: No, score=-0.95 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gXZIN30XvmHL for ; Wed, 26 Sep 2012 00:19:26 -0700 (PDT) Received: from ipo2-out.fzu.cz (ipo2-out.fzu.cz [147.231.27.21]) by ietfa.amsl.com (Postfix) with ESMTP id C743C21F87C3 for ; Wed, 26 Sep 2012 00:19:25 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqoCAFKrYlCT5xpZgWdsb2JhbABFhURHuVcjAQEWJieCIAEBBSNVEQsYCRYLAgIJAwIBAgFFEwgBAYgBpwWTFIs0gk+CDoESA45sgSCFWoEVkXyBYQ X-IronPort-AV: E=Sophos;i="4.80,488,1344204000"; d="asc'?scan'208";a="470699" Received: from freja.fzu.cz ([147.231.26.89]) by ipo2-out.fzu.cz with ESMTP; 26 Sep 2012 09:19:24 +0200 Received: from svist.flaska.net (pc069c.fzu.cz [147.231.27.69]) by freja.fzu.cz (Postfix) with ESMTPSA id B39E93DA82 for ; Wed, 26 Sep 2012 09:19:24 +0200 (CEST) Message-ID: <5062AC5B.6070908@flaska.net> Date: Wed, 26 Sep 2012 09:18:51 +0200 From: =?UTF-8?B?SmFuIEt1bmRyw6F0?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: imapext@ietf.org References: In-Reply-To: X-Enigmail-Version: 1.4.3 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig45068E2C06CDA93AAA84E467" Subject: Re: [imapext] Preparing for WGLC on IMAP MOVE: AD review 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, 26 Sep 2012 07:19:27 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig45068E2C06CDA93AAA84E467 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 09/25/12 02:32, Barry Leiba wrote: > Responses to this from anyone else (besides Ned)? > Arnt? Bron? Jan? Timo? Dan? > Should Arnt just roll in my two reviews, modulo Ned's responses, and > we're ready to go? Or what? I've tried to follow the discussion and don't have any objection to various changes which have been proposed. I also think that it's time for an updated draft -- and I'll be happy to read it thoroughly. With kind regards, Jan --=20 Trojita, a fast e-mail client -- http://trojita.flaska.net/ --------------enig45068E2C06CDA93AAA84E467 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlBirFsACgkQamXfqERyJReZ9wCaA5WJ1SqFFrWU/35u5ewgRjW5 1x4An0LOENK/9SRnXWc6MGJHfwFgAMu6 =2zx0 -----END PGP SIGNATURE----- --------------enig45068E2C06CDA93AAA84E467-- From barryleiba.mailing.lists@gmail.com Wed Sep 26 08:55:28 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 AF47821F84A2 for ; Wed, 26 Sep 2012 08:55:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.959 X-Spam-Level: X-Spam-Status: No, score=-102.959 tagged_above=-999 required=5 tests=[AWL=0.018, 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 Ot5-CwT0XePT for ; Wed, 26 Sep 2012 08:55:28 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id DF64A21F849D for ; Wed, 26 Sep 2012 08:55:27 -0700 (PDT) Received: by lbok13 with SMTP id k13so2150083lbo.31 for ; Wed, 26 Sep 2012 08:55:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=1CD4xilJ3SLnwxCc1pBHjguEqI51CzsX9Tej/bObia4=; b=KyWaDggyKhf24YgccTXFnSCFsXQfWQU5IKxgj9pJJKIfE3YmWYMFx380qe7ELRVXbp WZdfgFBNv+dci2P5bcrmj4983p2Ho70HrsxQNRTYjgJ1NzMtSoChxUp1+v25DYTDRl8L Jm69W/aKDdx+505NyxU+rLCnm6eT+egPL3ArGFU+uWP0uMBdvFhMXEKjNX1WcZ5GM6XJ uKWMTu+XdwGnE0FMTn4AyeNUUxM06Tc7S/p7A5MBNGtalfGRLvOnY0jz02zf0OYAEedV xPhrRYOh6Gt3yG99R+xEmYaOwkHzfWy0zOEtOzXXcF5DyNg8IW76qMVT+tzH1neQtSrl dd1A== MIME-Version: 1.0 Received: by 10.152.132.168 with SMTP id ov8mr981478lab.0.1348674926883; Wed, 26 Sep 2012 08:55:26 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.112.91.33 with HTTP; Wed, 26 Sep 2012 08:55:26 -0700 (PDT) In-Reply-To: <1348602587.18365.140661132619417.766B1A99@webmail.messagingengine.com> References: <1DE983233DBBEB4A81F18FABD8208D762312F4F7@XMB163CNC.rim.net> <1348602587.18365.140661132619417.766B1A99@webmail.messagingengine.com> Date: Wed, 26 Sep 2012 11:55:26 -0400 X-Google-Sender-Auth: _-yM-1UPyyNQ9XwbnNZFd7RJhew Message-ID: From: Barry Leiba To: Bron Gondwana , Arnt Gulbrandsen Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Zoltan Ordogh , "imapext@ietf.org" Subject: Re: [imapext] MOVE - A few late comments 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, 26 Sep 2012 15:55:28 -0000 >> Since the UID MOVE command consist of three individual commands (COPY, S= TORE, EXPUGE), it also triggers execution of the extensions (if any) to the= se commands on the server-side. Consequently, the UID MOVE command returns = response codes of each command the their extensions (i.e. COPYUID, TRYCREAT= E, etc.). > > Now are you sure you've read all the discussion leading up to this? > Because we've been leaning more the other way, de-emphasising the > individual commands. Indeed, and in a number of ways, Zoltan's review makes it clear that we need an updated draft that addresses the comments so far, so that people aren't reviewing what's basically old text. Arnt, can you do this soon, so we can get fresh reviews? Barry From prvs=3616ac2120=zordogh@rim.com Wed Sep 26 09:11:42 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 1626521F851E for ; Wed, 26 Sep 2012 09:11:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.902 X-Spam-Level: X-Spam-Status: No, score=-4.902 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_53=0.6, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] 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 ylm2utefhp8d for ; Wed, 26 Sep 2012 09:11:40 -0700 (PDT) Received: from mhs061cnc.rim.net (mhs061cnc.rim.net [208.65.73.35]) by ietfa.amsl.com (Postfix) with ESMTP id 5CB6F21F84DC for ; Wed, 26 Sep 2012 09:11:40 -0700 (PDT) X-AuditID: 0a412830-b7fab6d000006b80-27-506329396b77 Received: from XCT105CNC.rim.net (xct105cnc.rim.net [10.65.161.205]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client did not present a certificate) by mhs061cnc.rim.net (SBG) with SMTP id FD.5F.27520.93923605; Wed, 26 Sep 2012 16:11:37 +0000 (GMT) Received: from XMB163CNC.rim.net ([fe80::5805:6acc:b23a:e0a6]) by XCT105CNC.rim.net ([fe80::d13d:b7a2:ae5e:db06%16]) with mapi id 14.02.0318.001; Wed, 26 Sep 2012 12:11:36 -0400 From: Zoltan Ordogh To: Bron Gondwana , "imapext@ietf.org" Thread-Topic: [imapext] MOVE - A few late comments Thread-Index: Ac2bUv89gx2B1v8/TlWM3MMXzdiZvAAJXJ+AACAjfNA= Date: Wed, 26 Sep 2012 16:11:36 +0000 Message-ID: <1DE983233DBBEB4A81F18FABD8208D762312F76B@XMB163CNC.rim.net> References: <1DE983233DBBEB4A81F18FABD8208D762312F4F7@XMB163CNC.rim.net> <1348602587.18365.140661132619417.766B1A99@webmail.messagingengine.com> In-Reply-To: <1348602587.18365.140661132619417.766B1A99@webmail.messagingengine.com> Accept-Language: en-US, en-CA Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.160.245] Content-Type: text/plain; charset="iso-8859-1" content-transfer-encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrKKsWRmVeSWpSXmKPExsXC5bjwrK6lZnKAwZ8/Mhbn9k5ls3g8i8uB yWPnqQNsHkuW/GQKYIpqYLRJSiwpC85Mz9O3s0nMy8svSSxJVUhJLU62VfJJTU/MUQgoyixL TK5UcMksTs5JzMxNLVJSyEyxVTJRUijISUxOzU3NK7FVSiwoSM1LUbLjUsAANkBlmXkKqXnJ +SmZeem2Sp7B/roWFqaWuoZKdroJnTwZp6/NZyo45VfRO/UqSwPjddsuRk4OCQETiWmLPrJB 2GISF+6tB7K5OIQE+pgkJm5tZ4RwtjJKvFzxnLmLkYODTUBVYs7VWJAGEQEfiVO9O1lAwsIC hhLPfuWCmCICRhKNPyIhKqwkNm/YwAhiswA1TmxuAbN5BTwkelYeYYGYPolRYu6pbWDTOQVC JDa2g9UwCshKrJ2zkhXEZhYQl7j1ZD4TxJkCEkv2nGeGsEUlXj7+xwphK0qsfnWLDaJeT+LG 1ClQtrbEsoWvmSH2CkqcnPmEZQKj6CwkY2chaZmFpGUWkpYFjCyrGAVzM4oNzAyT85L1ijJz 9fJSSzYxghOBhsEOxvfvLQ4xCnAwKvHwfudKDhBiTSwrrsw9xCjBwawkwvssKylAiDclsbIq tSg/vqg0J7X4EKMFMFQmMktxJ+cDk1ReSbyxgQEKR0mc9/e5xAAhgXRgeslOTS1ILYJpZeLg BBnNJSVSDEwSqUWJpSUZ8aBUFl8MTGZSDYwc2ooXfKrnHkp4q7mp9rtsxEazK0f9apVsDZdr OcoXSFyf+6MtWfyG1u4Alkyx2JraLnkt4/LwOI3MsCd7f5ez6897vMmidH3K4gL/X76GnKrW 0/TXahlteimb4F4Y355p67bqoMlMvu8GhWd2CrQfUW7c5BPQuTrRUEX4V65vw/fy36s6lFiK MxINtZiLihMBg+FSzjgDAAA= Subject: Re: [imapext] MOVE - A few late comments 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, 26 Sep 2012 16:11:42 -0000 > -----Original Message----- > From: Bron Gondwana [mailto:brong@fastmail.fm] > Sent: Tuesday, September 25, 2012 15:50 > To: Zoltan Ordogh; imapext@ietf.org > Subject: Re: [imapext] MOVE - A few late comments > > On Tue, Sep 25, 2012, at 09:21 PM, Zoltan Ordogh wrote: > > Section 2: "This document defines an IMAP extension to move messages > from one mailbox to another." > > > > This document defines new IMAP commands to move messages? > > If it adds a CAPABILITY, it's an EXTENSION, right? > [Z=D6r] Right. However, and extension does not "do" anything (does not move= messages); the commands defined in that extension do. > > Section 2: "This function (very common in MUA UIs) is not provided by > stock IMAP ..." > > > > What is "stock imap"? One particular spec/product? > > RFC3501 > [Z=D6r] Then put that there. > > Section 3: "each message SHOULD either be moved or unaffected" > > > > I'd say MUST; there's no third option. > > > > > > > > Section 3: "The server SHOULD NOT leave a message in neither or both > mailboxes afterwards" > > > > I'd say MUST NOT; leave no room for fuzzy state. > > I can imagine failure modes on a server which doesn't have global > transactional state where the message is committed to the destination > mailbox but not yet removed from the source mailbox when something dies. > Hence MUST NOT makes it significantly harder to implement. > > > I'm happy with > > "MUST NOT leave a message neither mailbox, and SHOULD > NOT leave a message in both mailboxes." > [Z=D6r] Here's an extension that moves your message on success, fails, fails= with copying the message or fails with the message disappearing. That's jus= t not acceptable. It is either successful and the message is moved, or it fa= ils with an error and nothing happens in the storage. Failing is ok. Introdu= cing duplicates and disappearing messages are not ok. If the command does n= ot work in a predictable manner, then this exercise is moot. > > Section 3: > > > > " UID MOVE is the same as the three-command sequence in all other > > respects, which implies that extensions which affect the three- > > command sequence also affect UID MOVE, and that response codes such > > as COPYUID, TRYCREATE and so on should be sent as appropriate." > > > > Isn't there a less complicated way of saying this? For example: > > > > Since the UID MOVE command consist of three individual commands > (COPY, STORE, EXPUGE), it also triggers execution of the extensions (if an= y) > to these commands on the server-side. Consequently, the UID MOVE > command returns response codes of each command the their extensions > (i.e. COPYUID, TRYCREATE, etc.). > > Now are you sure you've read all the discussion leading up to this? > Because we've been leaning more the other way, de-emphasising the > individual commands. I'm not sure that your wording is less complicated. > > That said, the original wording is pretty fuzzy, and contains a lower case > "should". > > Perhaps this? > > "If the server supports extentions to COPY, STORE or EXPUNGE then it > SHOULD apply those same extensions to MOVE and return the same > responses (i.e. COPYUID, TRYCREATE, etc.) as if it was running the > three-command sequence in order" > [Z=D6r] I understand that drafts (that are about to become RFCs) should leav= e no room for misinterpretation and should not require following any discuss= ion on any mailing list. If it does, then it means that the draft is not rea= dy yet. Having said that, if there's a reason for doing this, it should be s= tated in the draft. Your proposal is better than the original, but, again, I do not understand: - why is it a "SHOULD"? Can the server hand-pick extensions it likes and ex= ecute only those? No. All supported extensions should be executed (i.e. it's= a MUST) - unless of course there was an error so it makes no sense to execu= te the rest. - It is not clear what responses to expect in case of an error. IMHO, only= the response from the command that failed is relevant. > > "Implementers will need to read > [RFC4315] to understand what UID > > EXPUNGE does. Implementing > [RFC4315] is not necessary." > > > > That sounds very awkward. Does it really make UIDPLUS a normative > reference? > > There's no non-UID version of EXPUNGE which allows you to expunge only a > subset of messages. [Z=D6r] I guess my IMAP is getting rusty. It's been a while, sorry. In any c= ase, I have to say that I am a bit lost now. I mean, if the MSN will have to be turned into a UID every time (for the sak= e of EXPUNGE and its response), then how come implementing RFC4315 is not re= quired? Just what kind of response would the server generate and how would t= he related extensions trigger without supporting RFC4315? > > > " Note that moving messages to the current mailbox is well-defined, so > > that MOVE is defined for all the cases where the COPY/STORE/EXPUNGE > > sequence is." > > > > This is not good enough, especially when ACLs are in use. > > > > Considering RFC4314 permissions: > > > > - COPY requires that I have 'r' right at the source and 'i' right at= the > destination. > > > > - STORE requires that I have 't' right at the source. > > > > - EXPUNGE requires that I have 'e' right at the source. > > > > Consequently, I must have 'i' at the destination and 'r'+'t'+'e' at the= source. > > Sorry, what's your problem here? If you don't have permissions, then the > command fails with a permission denied response (possibly EEXIST if you > don't even have rights to list the destination) > > And in this case, since source and destination are the same... > > "moving messages to the current mailbox" > > You obviously must have "irte" on the current mailbox to succeed. > [Z=D6r] The problem is the sentence. I was under the impression that it aims= to clarify the circumstances under which the MOVE command can be used. Without ACLs, the meaning of this sentence is unclear. With ACLs, it is just as unclear, but at least there's a section later that= could be referenced. So, I'd like to see this sentence improved and in case ACL is in use, a cros= s-reference to section 4.2 would be nice. > > Section 3: > > > > " The MOVE command performs the same actions UID MOVE. Notably, > the > > > > server may send EXPUNGE (or VANISHED) messages before the tagged > > > > response, so the client cannot safely send more commands with MSN > > > > arguments while the server is processing MOVE." > > > > All right, but does it trigger extensions the same way UID MOVE does? > > > > Some extensions do not operate with UIDs. > > > > Also, a server implementation could translate MSNs to UIDs during > execution - which would trigger extensions hooked onto UID, too (even > though MSNs were used in the request). I.e. If UIDPLUS were to fire when > MSNs were used in the MOVE command, would that break the client? > > > > Any thoughts? > > You have a point here. Hmm. > > . copy 1:2 inbox.sub > . OK [COPYUID 1348602306 1:2 1:2] Completed > > Looks like I used MSNs and got a COPYUID response from Cyrus on my local > testbed. We have all sorts of clients talk to our servers, and I've never= seen a > bug report that COPYUID confused any of them. > > Do you know any clients that would be confused? [Z=D6r] Thanks for running a quick test. Timo's response explained this, so I guess this is a non-issue. Kiitos, Timo= ! Would it be of value to capture Timo's response in the draft? > > > Section 4.2: > > > > "it requires the same ACL rights as the union of those three commands" > > > > The union of three commands is a command-triplet, not access rights. > > > > I think what you want to say is that the UID MOVE requires that all > permissions that those three commands require if executed one-by-one. > > > > What about the MSN MOVE command? (this is clearly missing from this > > section) > > Are there any MSN commands which require different ACLs than their UID > equivalents? > [Z=D6r] That's not the point I was trying to make. Let me try again. There are two points actually. The first point is a request for improving the language because the result o= f the "union of those three commands" is not an access right. The result is= a command-triplet. I am guessing that the text intends to say that to execu= te the MOVE command, all permissions need to be in place, just as if those c= ommands were executed one after the other by the client. Onto the second point. The extension includes two commands: UID MOVE and MOV= E. The latter is not addressed in section 4.2. I guess removing 'UID' from 'UID MOVE' would address this. > > Section 6: > > > > " This document is believed to add no security problems." > > > > Provided that the server does verify that all required permissions are i= n > place. > > Well, yeah - duh. If you don't verify ACLs as specified in the other part= s of > the document, then you'll have a security problem. > [Z=D6r] I think you misunderstood because I was not clear. Perhaps this is c= learer: The server verifies all required permissions for all three commands. I.e. it= does not just check the permission for COPY and executes the rest, but it a= lso verifies the permission for STORE and EXPUNGE as well. Ideally, the serv= er should verify all these permission prior to executing the command so it w= ould not run into a scenario when a user can COPY, STORE but not EXPUGE; the= server would have to roll back the whole thing. > Bron. [Z=D6r] Thank you Bron, I appreciate taking your time and responding an thes= e issues. > -- > Bron Gondwana > brong@fastmail.fm --------------------------------------------------------------------- This transmission (including any attachments) may contain confidential infor= mation, privileged material (including material protected by the solicitor-c= lient or other applicable privileges), or constitute non-public information.= Any use of this information by anyone other than the intended recipient is= prohibited. If you have received this transmission in error, please immedia= tely reply to the sender and delete this information from your system. Use,= dissemination, distribution, or reproduction of this transmission by uninte= nded recipients is not authorized and may be unlawful. From barryleiba.mailing.lists@gmail.com Wed Sep 26 09:21: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 C67A721F8587 for ; Wed, 26 Sep 2012 09:21:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.961 X-Spam-Level: X-Spam-Status: No, score=-102.961 tagged_above=-999 required=5 tests=[AWL=0.016, 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 l5H+i9q8ig-Y for ; Wed, 26 Sep 2012 09:21:36 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id DC62121F8588 for ; Wed, 26 Sep 2012 09:21:35 -0700 (PDT) Received: by lbok13 with SMTP id k13so2192516lbo.31 for ; Wed, 26 Sep 2012 09:21:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=556lFr8vtMetb9f3eoi9nlE/Ut/We9/7TrdRpc6zmHQ=; b=aHTCXdQMv67TatgbsPueY2aBvhBt2Z2FC5phej0uP2CKhcqa3lxSSyEKbgxLRSpPcq OVQMyqOYOF4sk0ZF05cic5br0MXpyrXIh9VxnM51eaHYpD5o8BnMR+IY4HIGUpf0cNg6 YX+ZHb9T77/sOBclaI73otwjs3pJq9XjcSAaKj5j7NIhs0EJgPlVfVldwz9N59hL/rhD fTycD057HP563mxZp4m+KvZjYPT290H0234cIH6HZm80Di6+0hbiqpptNYxZ95l9oYif btehcXHFm0tE9DgeMNaMDlG4SDgq61eeNluTxfxEsNP/8BrIo8IYDnQTxb75GLJw5mST vtTQ== MIME-Version: 1.0 Received: by 10.152.104.44 with SMTP id gb12mr974738lab.29.1348676493558; Wed, 26 Sep 2012 09:21:33 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.112.91.33 with HTTP; Wed, 26 Sep 2012 09:21:33 -0700 (PDT) In-Reply-To: <1DE983233DBBEB4A81F18FABD8208D762312F76B@XMB163CNC.rim.net> References: <1DE983233DBBEB4A81F18FABD8208D762312F4F7@XMB163CNC.rim.net> <1348602587.18365.140661132619417.766B1A99@webmail.messagingengine.com> <1DE983233DBBEB4A81F18FABD8208D762312F76B@XMB163CNC.rim.net> Date: Wed, 26 Sep 2012 12:21:33 -0400 X-Google-Sender-Auth: IYojYifgd5QFeJiONcDHVVKRBEg Message-ID: From: Barry Leiba To: Zoltan Ordogh Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Bron Gondwana , "imapext@ietf.org" Subject: Re: [imapext] MOVE - A few late comments 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, 26 Sep 2012 16:21:36 -0000 >> > Section 3: "each message SHOULD either be moved or unaffected" >> > >> > I'd say MUST; there's no third option. >> > >> > Section 3: "The server SHOULD NOT leave a message in neither or both >> mailboxes afterwards" >> > >> > I'd say MUST NOT; leave no room for fuzzy state. >> >> I can imagine failure modes on a server which doesn't have global >> transactional state where the message is committed to the destination >> mailbox but not yet removed from the source mailbox when something dies. >> Hence MUST NOT makes it significantly harder to implement. ... > [Z=D6r] Here's an extension that moves your message on success, fails, fa= ils with > copying the message or fails with the message disappearing. That's just n= ot > acceptable. It is either successful and the message is moved, or it fails= with an > error and nothing happens in the storage. Failing is ok. Introducing dupl= icates and > disappearing messages are not ok. If the command does not work in a pred= ictable > manner, then this exercise is moot. I have to say that I agree with Zoltan here. We don't allow other IMAP commands that leave things in indeterminate states, and I don't think we should define this one that way. COPY is clear: if it succeeds, you have two copies of the message. If it fails, nothing has changed. It would be odd to say that if it succeeds, a copy SHOULD exist in the target mailbox. No, if it succeeds, a copy MUST exist there. If a server, with a particular back-end mailstore, can't reliably implement MOVE so that it works reliably (if it succeeds, the message is moved and exists only in the target; if it fails, the message is not moved and exists only in the source), then it simply shouldn't implement this extension. It may, of course, choose to implement it anyway, knowing that it might sometimes be in violation of this MUST, but the protocol shouldn't waffle about it. Barry From blong@google.com Wed Sep 26 09:30: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 9199821F852B for ; Wed, 26 Sep 2012 09:30:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.976 X-Spam-Level: X-Spam-Status: No, score=-102.976 tagged_above=-999 required=5 tests=[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 ZUPzVKJXrOy6 for ; Wed, 26 Sep 2012 09:30:06 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id A22BC21F8504 for ; Wed, 26 Sep 2012 09:30:06 -0700 (PDT) Received: by vcbfl11 with SMTP id fl11so941700vcb.31 for ; Wed, 26 Sep 2012 09:30:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-system-of-record; bh=+Mk4UhqX/2SgRB6MX9IjPaOL7gOX9ajfNz5gBviqa+4=; b=cmr7BYKHP0vqfchc+sLZDNUQoLR6Ljuftn6pliSaQ8ZTJ+7PZVYdltDBs41Hawmegt xew2ra3sDAsFuF9VhCkLFhpVuQV1MH9CGyY4FJC7HXPjogSYyJ1tyKGo7e+kTnToNmRJ YUuMK86r+uuZnRBhy67kPVQRkB2LfPsH4/I64obEnaLRlPsQ93dD5m5wFKBYcVmy1NIn zIMa+9tU8YnQpCQd8pyYPO65Zay+l2vlLTEfS5LQKJ964BBJ7W84ecv5dDaHkPEQENjf eNNXjiUjAw+9J1O6sPrXk9mGRtZTg6GQMArq+sHivpUtMqGu9DUl/Pkzq2phsgl/6JMi +2+g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=+Mk4UhqX/2SgRB6MX9IjPaOL7gOX9ajfNz5gBviqa+4=; b=gG0BK2meqUunFMIZo2Z9GL64tI66rSMErLuA2BN+apHzWLhzGhwlCIN/I6edCUOCPC Qq55PpnSVTIBVCTzi7wfVT6XrPcHWJHfObxwqH4RV2tdUiC3aZKwZe+WMk4YnSiAJd4q gJosuUEXa8+Jk45bl61kIOojWs9Dx22N9UMdHudmUATt78B5sEQZbCF2m/izDN9ixmgH +iB0VvQXTJj7QK3Q/f9Ybz+u0B0bWVo/MNA/dgbAWmnk/uyCnnLm1Jhcc3iGTkrmx1T5 mys3Mzo8rcmjnHn0LOsnmnRy6BJK5eTbeJ+rn1gXcGGEOBDjW4sfb6LLAJqbzwUKthdG kHmg== Received: by 10.52.37.229 with SMTP id b5mr457411vdk.70.1348677006116; Wed, 26 Sep 2012 09:30:06 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.37.229 with SMTP id b5mr457403vdk.70.1348677006032; Wed, 26 Sep 2012 09:30:06 -0700 (PDT) Received: by 10.58.64.78 with HTTP; Wed, 26 Sep 2012 09:30:06 -0700 (PDT) In-Reply-To: References: <1DE983233DBBEB4A81F18FABD8208D762312F4F7@XMB163CNC.rim.net> <1348602587.18365.140661132619417.766B1A99@webmail.messagingengine.com> <1DE983233DBBEB4A81F18FABD8208D762312F76B@XMB163CNC.rim.net> Date: Wed, 26 Sep 2012 09:30:06 -0700 Message-ID: From: Brandon Long To: Barry Leiba Content-Type: multipart/alternative; boundary=bcaec51d2e44dc814904ca9d5560 X-System-Of-Record: true X-Gm-Message-State: ALoCoQk8iNYy6RvVLwdLB9kbESJ0kqsYoLAn5JpPkfI/h2sGLuzQVf4O0U5syfNAVALB6qc69LpdKIVQYpSwvWDciurLxyEKQLW+340BF2V8OAftbFnG5+8q9PHqRQARUqque5+wclclgfdlRmDKKvOK68s4siAtnrKKpziJlVUBgdToFcqhb9SL3mMaoXxwgxDMnLEWP3PM Cc: Bron Gondwana , Zoltan Ordogh , "imapext@ietf.org" Subject: Re: [imapext] MOVE - A few late comments 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, 26 Sep 2012 16:30:07 -0000 --bcaec51d2e44dc814904ca9d5560 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Wed, Sep 26, 2012 at 9:21 AM, Barry Leiba wrote= : > >> > Section 3: "each message SHOULD either be moved or unaffected" > >> > > >> > I'd say MUST; there's no third option. > >> > > >> > Section 3: "The server SHOULD NOT leave a message in neither or both > >> mailboxes afterwards" > >> > > >> > I'd say MUST NOT; leave no room for fuzzy state. > >> > >> I can imagine failure modes on a server which doesn't have global > >> transactional state where the message is committed to the destination > >> mailbox but not yet removed from the source mailbox when something die= s. > >> Hence MUST NOT makes it significantly harder to implement. > ... > > [Z=D6r] Here's an extension that moves your message on success, fails, > fails with > > copying the message or fails with the message disappearing. That's just > not > > acceptable. It is either successful and the message is moved, or it > fails with an > > error and nothing happens in the storage. Failing is ok. Introducing > duplicates and > > disappearing messages are not ok. If the command does not work in a > predictable > > manner, then this exercise is moot. > > I have to say that I agree with Zoltan here. We don't allow other > IMAP commands that leave things in indeterminate states, and I don't > think we should define this one that way. COPY is clear: if it > succeeds, you have two copies of the message. If it fails, nothing > has changed. It would be odd to say that if it succeeds, a copy > SHOULD exist in the target mailbox. No, if it succeeds, a copy MUST > exist there. > > If a server, with a particular back-end mailstore, can't reliably > implement MOVE so that it works reliably (if it succeeds, the message > is moved and exists only in the target; if it fails, the message is > not moved and exists only in the source), then it simply shouldn't > implement this extension. It may, of course, choose to implement it > anyway, knowing that it might sometimes be in violation of this MUST, > but the protocol shouldn't waffle about it. > At the very least, it should be MUST that a message shouldn't be in neither= . Brandon --bcaec51d2e44dc814904ca9d5560 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On Wed, S= ep 26, 2012 at 9:21 AM, Barry Leiba <barryleiba@com= puter.org> wrote:
>> > Section 3: &= quot;each message SHOULD either be moved or unaffected"
>> >
>> > I'd say MUST; there's no third option.
>> >
>> > Section 3: "The server SHOULD NOT leave a message in nei= ther or both
>> mailboxes afterwards"
>> >
>> > I'd say MUST NOT; leave no room for fuzzy state.
>>
>> I can imagine failure modes on a server which doesn't have glo= bal
>> transactional state where the message is committed to the destinat= ion
>> mailbox but not yet removed from the source mailbox when something= dies.
>> Hence MUST NOT makes it significantly harder to implement.
...
> [Z=D6r] Here's an extension that moves your mess= age on success, fails, fails with
> copying the message or fails with the message disappearing. That's= just not
> acceptable. It is either successful and the message is moved, or it fa= ils with an
> error and nothing happens in the storage. Failing is ok. Introducing d= uplicates and
> disappearing messages are not ok. If the command =A0does not work in a= predictable
> manner, then this exercise is moot.

I have to say that I agree with Zoltan here. =A0We don't allow ot= her
IMAP commands that leave things in indeterminate states, and I don't think we should define this one that way. =A0COPY is clear: if it
succeeds, you have two copies of the message. =A0If it fails, nothing
has changed. =A0It would be odd to say that if it succeeds, a copy
SHOULD exist in the target mailbox. =A0No, if it succeeds, a copy MUST
exist there.

If a server, with a particular back-end mailstore, can't reliably
implement MOVE so that it works reliably (if it succeeds, the message
is moved and exists only in the target; if it fails, the message is
not moved and exists only in the source), then it simply shouldn't
implement this extension. =A0It may, of course, choose to implement it
anyway, knowing that it might sometimes be in violation of this MUST,
but the protocol shouldn't waffle about it.

At the very least, it should be MUST that a message shouldn't = be in neither.

Brandon=A0
--bcaec51d2e44dc814904ca9d5560-- From brong@fastmail.fm Wed Sep 26 13:44: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 DC98921F8505 for ; Wed, 26 Sep 2012 13:44:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.449 X-Spam-Level: X-Spam-Status: No, score=-3.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wz+DH-ba++6a for ; Wed, 26 Sep 2012 13:44:24 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) by ietfa.amsl.com (Postfix) with ESMTP id 6002921F8582 for ; Wed, 26 Sep 2012 13:44:24 -0700 (PDT) Received: from compute1.internal (compute1.nyi.mail.srv.osa [10.202.2.41]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id 33979203BB; Wed, 26 Sep 2012 16:44:23 -0400 (EDT) Received: from web6.nyi.mail.srv.osa ([10.202.2.216]) by compute1.internal (MEProxy); Wed, 26 Sep 2012 16:44:23 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=fastmail.fm; h= message-id:from:to:cc:mime-version:content-transfer-encoding :content-type:subject:date:in-reply-to:references; s=mesmtp; bh= rwZqs2Ou2pb1Bcb4+zmMqiJsAns=; b=NDkn+RjHPJG6nexPyurTGcGKRE39sRul CgqiNtqz1qHY6adPt/a6+rtrYREFraHhnjtKU6zR0wcc5lBE8X6J+YeK+xof3nWe jI42pt7XfsQzyhFqGV6RTAR74nsFx8BL76wJgcFLgU3Ezv+7g46HSDYXkhzaJA8i yzokiKmqxLw= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=message-id:from:to:cc:mime-version :content-transfer-encoding:content-type:subject:date:in-reply-to :references; s=smtpout; bh=rwZqs2Ou2pb1Bcb4+zmMqiJsAns=; b=ArSS4 7ggoz9K2oNEqFRCfxmFzuuGwWZ0o0NSe5Ppi5npCtkJwaf9o8hIyDvjOBsMTo8Nu XeHSU1lURtQXrrGlGBKixwT0x9mYqyZLqC5FEMXqJwjUUL8Cdlgv48YYGXRychTl yDsN1pjZJITMh4rX1sVoX6XD1OavBHEx9+I/pA= Received: by web6.nyi.mail.srv.osa (Postfix, from userid 99) id F0245210C1; Wed, 26 Sep 2012 16:44:22 -0400 (EDT) Message-Id: <1348692262.28413.140661133130989.6CCAE683@webmail.messagingengine.com> X-Sasl-Enc: 31UGrzG+MmZHvuGjKLnpyVcQICCZ8k5oRTyiI3EROZN7 1348692262 From: Bron Gondwana To: Brandon Long , Barry Leiba MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain X-Mailer: MessagingEngine.com Webmail Interface Date: Wed, 26 Sep 2012 22:44:22 +0200 In-Reply-To: References: <1DE983233DBBEB4A81F18FABD8208D762312F4F7@XMB163CNC.rim.net> <1348602587.18365.140661132619417.766B1A99@webmail.messagingengine.com> <1DE983233DBBEB4A81F18FABD8208D762312F76B@XMB163CNC.rim.net> Cc: Zoltan Ordogh , "imapext@ietf.org" Subject: Re: [imapext] MOVE - A few late comments 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, 26 Sep 2012 20:44:31 -0000 On Wed, Sep 26, 2012, at 06:30 PM, Brandon Long wrote: > On Wed, Sep 26, 2012 at 9:21 AM, Barry Leiba wrote: > > I have to say that I agree with Zoltan here. We don't allow other > > IMAP commands that leave things in indeterminate states, and I don't > > think we should define this one that way. COPY is clear: if it > > succeeds, you have two copies of the message. If it fails, nothing > > has changed. It would be odd to say that if it succeeds, a copy > > SHOULD exist in the target mailbox. No, if it succeeds, a copy MUST > > exist there. Sorry - I think I got crossed wires here. Of course if the command succeeds it MUST exist in the destination. No ifs, no buts. If it fails, then it SHOULD be in just one, and MUST be in at least one. > > If a server, with a particular back-end mailstore, can't reliably > > implement MOVE so that it works reliably (if it succeeds, the message > > is moved and exists only in the target; if it fails, the message is > > not moved and exists only in the source), then it simply shouldn't > > implement this extension. It may, of course, choose to implement it > > anyway, knowing that it might sometimes be in violation of this MUST, > > but the protocol shouldn't waffle about it. > > > > At the very least, it should be MUST that a message shouldn't be in neither. Absolutely! Bron. -- Bron Gondwana brong@fastmail.fm From barryleiba@gmail.com Wed Sep 26 15:22: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 0B32221F8526 for ; Wed, 26 Sep 2012 15:22:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.349 X-Spam-Level: X-Spam-Status: No, score=-103.349 tagged_above=-999 required=5 tests=[AWL=0.250, BAYES_00=-2.599, 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 2bK2KQnvMfYJ for ; Wed, 26 Sep 2012 15:22:49 -0700 (PDT) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4C93721F8464 for ; Wed, 26 Sep 2012 15:22:48 -0700 (PDT) Received: by qcac10 with SMTP id c10so1036455qca.31 for ; Wed, 26 Sep 2012 15:22:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=nDogHSkObzWQXihCpbaHCY5xZ1L2fpj7yaeG2Xe9DZ0=; b=TC/sWb/xuuAsMk6ty73sDdzjcfrDMd5DFPwVXTrFzvZKqPDnXB349t7GxVDXcN/4iI q+HX9ukRfhHyRoXb3WVeKyRwGMYBdPikeo3qQ4KYM6CkGim0JvIjJKfe1ZkrX2FWKj6z 2kYsg8thlFafd3wYiMpJBqRnyT9ivVgve0QYkQouRONtaGUEZCxIbZWMZO8ba7ckjPQu eKNrr6BpPVBfxdDIcJ8Op/T/xDgWW3XbnAnEN0tW99vV6VMUj+L5TtJhu//Ogwq9ppjr +NY+RHg+6of7XN0kHIE4OK+LbsxPYaEOEVpwRp8cN7yCJlahVGHdQe/etEZFbTm2kPuu jsEg== Received: by 10.224.189.5 with SMTP id dc5mr5263471qab.89.1348698167832; Wed, 26 Sep 2012 15:22:47 -0700 (PDT) Received: from neptune.local ([70.42.157.22]) by mx.google.com with ESMTPS id g18sm6291501qan.1.2012.09.26.15.22.45 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 26 Sep 2012 15:22:47 -0700 (PDT) Sender: Barry Leiba Message-ID: <50638030.60505@computer.org> Date: Wed, 26 Sep 2012 18:22:40 -0400 From: Barry Leiba User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.9) Gecko/20100915 Thunderbird/3.1.4 MIME-Version: 1.0 To: Bron Gondwana References: <1DE983233DBBEB4A81F18FABD8208D762312F4F7@XMB163CNC.rim.net> <1348602587.18365.140661132619417.766B1A99@webmail.messagingengine.com> <1DE983233DBBEB4A81F18FABD8208D762312F76B@XMB163CNC.rim.net> <1348692262.28413.140661133130989.6CCAE683@webmail.messagingengine.com> In-Reply-To: <1348692262.28413.140661133130989.6CCAE683@webmail.messagingengine.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Zoltan Ordogh , "imapext@ietf.org" Subject: Re: [imapext] MOVE - A few late comments 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, 26 Sep 2012 22:22:51 -0000 Bron Gondwana said the following: > On Wed, Sep 26, 2012, at 06:30 PM, Brandon Long wrote: >> On Wed, Sep 26, 2012 at 9:21 AM, Barry Leiba wrote: >>> I have to say that I agree with Zoltan here. We don't allow other >>> IMAP commands that leave things in indeterminate states, and I don't >>> think we should define this one that way. COPY is clear: if it >>> succeeds, you have two copies of the message. If it fails, nothing >>> has changed. It would be odd to say that if it succeeds, a copy >>> SHOULD exist in the target mailbox. No, if it succeeds, a copy MUST >>> exist there. > Sorry - I think I got crossed wires here. Of course if the command > succeeds it MUST exist in the destination. No ifs, no buts. If it > fails, then it SHOULD be in just one, and MUST be in at least one. No, I don't think that's sufficient. The command has to work reliably. That means that if it *fails*, the result has to be well defined. The only reasonable well-defined failure mode is that the message MUST exist only in the source. As I said, your implementation can choose to violate that if it has to, using the alternative that you give above. But the *protocol* needs to specify it cleanly, I think. Barry From brong@fastmail.fm Wed Sep 26 15:39:55 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 E937D21F8574 for ; Wed, 26 Sep 2012 15:39:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.487 X-Spam-Level: X-Spam-Status: No, score=-3.487 tagged_above=-999 required=5 tests=[AWL=0.113, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QkgUTAtXy7V2 for ; Wed, 26 Sep 2012 15:39:55 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) by ietfa.amsl.com (Postfix) with ESMTP id 6F75C21F854F for ; Wed, 26 Sep 2012 15:39:55 -0700 (PDT) Received: from compute2.internal (compute2.nyi.mail.srv.osa [10.202.2.42]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id E26AF20779; Wed, 26 Sep 2012 18:39:54 -0400 (EDT) Received: from web6.nyi.mail.srv.osa ([10.202.2.216]) by compute2.internal (MEProxy); Wed, 26 Sep 2012 18:39:54 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=fastmail.fm; h= message-id:from:to:cc:mime-version:content-transfer-encoding :content-type:in-reply-to:references:subject:date; s=mesmtp; bh= vKDIkmO594RWBBJO7bOtvoBN4Rg=; b=FLyQYpuEu8qPDVyBqSicOfMeakYmjh55 KCvy+AK3SkhudlyOvHbgwHRjWvB0egGN1C9+N2fR7XfLKChfo8Ev2xdf6aNAbLvX G8cbVH11nmlD/+CqRA8EeK46UKVu9cSKS77lLziXP2CFWleqcmOWyqsFVXccKIjY 79AXGF8y2bA= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=message-id:from:to:cc:mime-version :content-transfer-encoding:content-type:in-reply-to:references :subject:date; s=smtpout; bh=vKDIkmO594RWBBJO7bOtvoBN4Rg=; b=Dyo B4ao5b1GltZbJl1Ai8ZruWn12P4tO6RIAd++mKykDnMfjE2kFwhaQ+xr5a9dtXON isYJl8ZNVfs9zuAwrLa6bUp7uwUvm/E7ztEdqaB9WaFvKIVgdPbyCplKMcaQyGZ0 a/0Z8+bKWRRo92mpRcPigGUu+B2ik9WwDYOmWJO4= Received: by web6.nyi.mail.srv.osa (Postfix, from userid 99) id A5A38210C1; Wed, 26 Sep 2012 18:39:54 -0400 (EDT) Message-Id: <1348699194.18781.140661133171885.2EBEEB87@webmail.messagingengine.com> X-Sasl-Enc: zT/+c4ZRJnB9aurEQAWbat7qAVzB5ODjDX2CciqUNOl1 1348699194 From: Bron Gondwana To: Barry Leiba MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain X-Mailer: MessagingEngine.com Webmail Interface In-Reply-To: <50638030.60505@computer.org> References: <1DE983233DBBEB4A81F18FABD8208D762312F4F7@XMB163CNC.rim.net> <1348602587.18365.140661132619417.766B1A99@webmail.messagingengine.com> <1DE983233DBBEB4A81F18FABD8208D762312F76B@XMB163CNC.rim.net> <1348692262.28413.140661133130989.6CCAE683@webmail.messagingengine.com> <50638030.60505@computer.org> Date: Thu, 27 Sep 2012 00:39:54 +0200 Cc: Zoltan Ordogh , "imapext@ietf.org" Subject: Re: [imapext] MOVE - A few late comments 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, 26 Sep 2012 22:39:56 -0000 On Thu, Sep 27, 2012, at 12:22 AM, Barry Leiba wrote: > Bron Gondwana said the following: > > On Wed, Sep 26, 2012, at 06:30 PM, Brandon Long wrote: > >> On Wed, Sep 26, 2012 at 9:21 AM, Barry Leiba wrote: > >>> I have to say that I agree with Zoltan here. We don't allow other > >>> IMAP commands that leave things in indeterminate states, and I don't > >>> think we should define this one that way. COPY is clear: if it > >>> succeeds, you have two copies of the message. If it fails, nothing > >>> has changed. It would be odd to say that if it succeeds, a copy > >>> SHOULD exist in the target mailbox. No, if it succeeds, a copy MUST > >>> exist there. > > Sorry - I think I got crossed wires here. Of course if the command > > succeeds it MUST exist in the destination. No ifs, no buts. If it > > fails, then it SHOULD be in just one, and MUST be in at least one. > > No, I don't think that's sufficient. The command has to work reliably. > That means that if it *fails*, the result has to be well defined. The > only reasonable well-defined failure mode is that the message MUST exist > only in the source. > > As I said, your implementation can choose to violate that if it has to, > using the alternative that you give above. But the *protocol* needs to > specify it cleanly, I think. You are right. I'm now convinced that the spec should say MUST. Bron ( if you don't get either answer from the server the usual network gremlin lack of determinism applies ) -- Bron Gondwana brong@fastmail.fm From tss@iki.fi Wed Sep 26 15:47:11 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 BF12B21F854F for ; Wed, 26 Sep 2012 15:47:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.431 X-Spam-Level: X-Spam-Status: No, score=-110.431 tagged_above=-999 required=5 tests=[AWL=0.168, 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 WPADB9I3wF3j for ; Wed, 26 Sep 2012 15:47:11 -0700 (PDT) Received: from dovecot.org (dovecot.org [193.210.130.67]) by ietfa.amsl.com (Postfix) with ESMTP id E29CA21F851B for ; Wed, 26 Sep 2012 15:47:10 -0700 (PDT) Received: from [192.168.10.101] (a88-112-255-76.elisa-laajakaista.fi [88.112.255.76]) by dovecot.org (Postfix) with ESMTP id E619C1AE87C3; Thu, 27 Sep 2012 01:47:08 +0300 (EEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Timo Sirainen In-Reply-To: <50638030.60505@computer.org> Date: Thu, 27 Sep 2012 01:47:08 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1DE983233DBBEB4A81F18FABD8208D762312F4F7@XMB163CNC.rim.net> <1348602587.18365.140661132619417.766B1A99@webmail.messagingengine.com> <1DE983233DBBEB4A81F18FABD8208D762312F76B@XMB163CNC.rim.net> <1348692262.28413.140661133130989.6CCAE683@webmail.messagingengine.com> <50638030.60505@computer.org> To: Barry Leiba X-Mailer: Apple Mail (2.1084) Cc: Bron Gondwana , Zoltan Ordogh , "imapext@ietf.org" Subject: Re: [imapext] MOVE - A few late comments 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, 26 Sep 2012 22:47:11 -0000 On 27.9.2012, at 1.22, Barry Leiba wrote: > Bron Gondwana said the following: >> On Wed, Sep 26, 2012, at 06:30 PM, Brandon Long wrote: >>> On Wed, Sep 26, 2012 at 9:21 AM, Barry Leiba = wrote: >>>> I have to say that I agree with Zoltan here. We don't allow other >>>> IMAP commands that leave things in indeterminate states, and I = don't >>>> think we should define this one that way. COPY is clear: if it >>>> succeeds, you have two copies of the message. If it fails, nothing >>>> has changed. It would be odd to say that if it succeeds, a copy >>>> SHOULD exist in the target mailbox. No, if it succeeds, a copy = MUST >>>> exist there. >> Sorry - I think I got crossed wires here. Of course if the command >> succeeds it MUST exist in the destination. No ifs, no buts. If it >> fails, then it SHOULD be in just one, and MUST be in at least one. >=20 > No, I don't think that's sufficient. The command has to work = reliably.=20 > That means that if it *fails*, the result has to be well defined. The > only reasonable well-defined failure mode is that the message MUST = exist > only in the source. >=20 > As I said, your implementation can choose to violate that if it has = to, > using the alternative that you give above. But the *protocol* needs = to > specify it cleanly, I think. For each individual message ok. But should all the messages be either = moved or none moved? Mainly should it fail and abort if some of the = messages were already expunged? COPY is defined to either copy all or = nothing. My MOVE implementation also moves all or nothing. But some = people wanted to use rename() and such that would make reverting in the = middle difficult.= From barryleiba@gmail.com Wed Sep 26 15:54: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 9FCAE21F851C for ; Wed, 26 Sep 2012 15:54:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.499 X-Spam-Level: X-Spam-Status: No, score=-103.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, 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 WzWxisJfX2vi for ; Wed, 26 Sep 2012 15:54:10 -0700 (PDT) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id A409D21F851E for ; Wed, 26 Sep 2012 15:54:09 -0700 (PDT) Received: by qcac10 with SMTP id c10so1056065qca.31 for ; Wed, 26 Sep 2012 15:54:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=atxjJ/jSu9LdHrpPt6l2ZaBbsGmKPzgqsLPhYyBZP0Q=; b=NzuxWSBIWmaSEhMevsZRCOmmCcL9tz7Bmrh/dNmwJHDs8MWpHwnc+HDaUMQo4T4On+ YDxIdsmcfbDwM/uAoUVYPOPoIqIqOdrkKa4yebGDyU60pIsid1/IKLzosw+te+vZCG5n evVYoLTNWXA4Ac5GFBSQvtN6Wl24ZnZ2yssaZg51x/smo0OCmW/1Dck4VBI6EOMFkCQN edIFxMOZKxnYbXPaptPrm4Qsvhsen6aCLH74WheC25maeSJsE/ZHfi76Pk9pKkcI84rf ssXESFH3sopcjck3k4ImbvxSV8NzmRD1EX8Ic3BaV4DB5mV7U6lC84oEpITKea11eWbe y+nQ== Received: by 10.224.181.198 with SMTP id bz6mr4418975qab.97.1348700049152; Wed, 26 Sep 2012 15:54:09 -0700 (PDT) Received: from neptune.local ([70.42.157.22]) by mx.google.com with ESMTPS id ep8sm6396697qab.22.2012.09.26.15.54.07 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 26 Sep 2012 15:54:08 -0700 (PDT) Sender: Barry Leiba Message-ID: <5063877A.1090609@computer.org> Date: Wed, 26 Sep 2012 18:53:46 -0400 From: Barry Leiba User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.9) Gecko/20100915 Thunderbird/3.1.4 MIME-Version: 1.0 To: Timo Sirainen References: <1DE983233DBBEB4A81F18FABD8208D762312F4F7@XMB163CNC.rim.net> <1348602587.18365.140661132619417.766B1A99@webmail.messagingengine.com> <1DE983233DBBEB4A81F18FABD8208D762312F76B@XMB163CNC.rim.net> <1348692262.28413.140661133130989.6CCAE683@webmail.messagingengine.com> <50638030.60505@computer.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Bron Gondwana , Zoltan Ordogh , "imapext@ietf.org" Subject: Re: [imapext] MOVE - A few late comments 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, 26 Sep 2012 22:54:10 -0000 > For each individual message ok. But should all the messages be either moved or none moved? Mainly should it fail and abort if some of the messages were already expunged? COPY is defined to either copy all or nothing. My MOVE implementation also moves all or nothing. But some people wanted to use rename() and such that would make reverting in the middle difficult. I'm OK with saying that the action for each message must be well defined, but allow for a group MOVE to fail in the middle. We should verify the consensus on that point, though. Barry From blong@google.com Wed Sep 26 16:04:45 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 26E1B21F8570 for ; Wed, 26 Sep 2012 16:04:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.976 X-Spam-Level: X-Spam-Status: No, score=-102.976 tagged_above=-999 required=5 tests=[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 8mvyqKt5sfvn for ; Wed, 26 Sep 2012 16:04:44 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 7A68D21F8568 for ; Wed, 26 Sep 2012 16:04:44 -0700 (PDT) Received: by vbbfc26 with SMTP id fc26so1437427vbb.31 for ; Wed, 26 Sep 2012 16:04:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-system-of-record; bh=5CmS/3ONvx0hf74xE/eUATp27m2FP0Kd7G1o+am7cGc=; b=HVKKBRyRyxaFEjJ3Ow8PBl7k5MS4CojGIAq7ir/Td+pK4AjfMhio8gLOcT3g93PNJ2 K6viQLBJkdGz2mRX57vRKPPMb7H6ELZywtGBlS6Z+NaXpWxdTqnQUfs6eOULNFex726/ +B5R7/q/czdZtv0CiW2MtSb8nuIKh3kGiCZ6K/3apjwxWB7Ks/gCsu22KhuR4kSs57v7 O1SUAlkpUJAKHJUxp3eQrLjYGxb55lqNIw1M+gfg8gNJXCNM5r+GrN7UUUfQZ29vR11j kRohrwIhpdDWxIDxKMMKWb/+oEyk2Oej2aqFa6aCefS/kyMAv8cjx5S/KgYd7bJvzJ/X Xmcw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=5CmS/3ONvx0hf74xE/eUATp27m2FP0Kd7G1o+am7cGc=; b=gONTkNOAOAbdW7GK8TvQ8YmSAu9BwSQhKJCrtPR3JuzQdkJggkwl2XrjGtbs2t/Y04 uDFtplUr3SBo+xm7GBFi4pELLQzclZHYV/n7/qGQlAvWo24CMC2xY4xleI/sZElRCz4E KSTy7OKgtZ28Kdehcj8UYLbne5gyRImkrOw9N9bKAvrtG01HINFi44Sx7UZgBDkanyaA COgDl2T7LPZzuthkm+vpCYSD65AQEMIlTWkg2H7N/9Xtm4C/QRceaB+FpG0SUXF2HX1i /wXSrHJzh9eiziUBTOaugHthFMAoY7RBe3KXrwLfWjuqa8oi17H5IcwYkuTXe3w03zyb TxgA== MIME-Version: 1.0 Received: by 10.52.76.40 with SMTP id h8mr925083vdw.123.1348700683687; Wed, 26 Sep 2012 16:04:43 -0700 (PDT) Received: by 10.58.64.78 with HTTP; Wed, 26 Sep 2012 16:04:43 -0700 (PDT) In-Reply-To: <5063877A.1090609@computer.org> References: <1DE983233DBBEB4A81F18FABD8208D762312F4F7@XMB163CNC.rim.net> <1348602587.18365.140661132619417.766B1A99@webmail.messagingengine.com> <1DE983233DBBEB4A81F18FABD8208D762312F76B@XMB163CNC.rim.net> <1348692262.28413.140661133130989.6CCAE683@webmail.messagingengine.com> <50638030.60505@computer.org> <5063877A.1090609@computer.org> Date: Wed, 26 Sep 2012 16:04:43 -0700 Message-ID: From: Brandon Long To: Barry Leiba Content-Type: multipart/alternative; boundary=20cf3071c70c28d8f204caa2d943 X-System-Of-Record: true X-Gm-Message-State: ALoCoQn25IidQvvwm5EXinrfEL5avRvAPU6My5VWnjXEIKS1eiNhi0h9A6aruLML8l20U7oilEen6BHHJWG/qQsPm5uruxorOH3LUWxL/EWAuDCW8o8M7+t+hHgDAupB8Be7XW9U8TvQYSJAwuF1JmX6PvrHLl9WQ3xv1D+xzCCrOLrUrtGAo3LDTtwZF8QtDO4aw7hNOCgm Cc: Timo Sirainen , Bron Gondwana , Zoltan Ordogh , "imapext@ietf.org" Subject: Re: [imapext] MOVE - A few late comments 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, 26 Sep 2012 23:04:45 -0000 --20cf3071c70c28d8f204caa2d943 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Sep 26, 2012 at 3:53 PM, Barry Leiba wrote: > > > For each individual message ok. But should all the messages be either > moved or none moved? Mainly should it fail and abort if some of the > messages were already expunged? COPY is defined to either copy all or > nothing. My MOVE implementation also moves all or nothing. But some people > wanted to use rename() and such that would make reverting in the middle > difficult. > I'm OK with saying that the action for each message must be well > defined, but allow for a group MOVE to fail in the middle. We should > verify the consensus on that point, though. > I'd rather not have yet another IMAP spec require transactional guarantee on an arbitrarily large number of messages. We can have 4B messages in a folder, I think its pretty insane to think that a MOVE of 4B messages either happened or didn't. Brandon --20cf3071c70c28d8f204caa2d943 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On Wed, S= ep 26, 2012 at 3:53 PM, Barry Leiba <barryleiba@com= puter.org> wrote:

> For each individual message ok. But should all the messages be either = moved or none moved? Mainly should it fail and abort if some of the message= s were already expunged? COPY is defined to either copy all or nothing. My = MOVE implementation also moves all or nothing. But some people wanted to us= e rename() and such that would make reverting in the middle difficult.
I'm OK with saying that the action for each message must be well<= br> defined, but allow for a group MOVE to fail in the middle. =A0We should
verify the consensus on that point, though.

=
I'd rather not have yet another IMAP spec require transactional gu= arantee on an arbitrarily large number of messages. =A0We can have 4B messa= ges in a folder, I think its pretty insane to think that a MOVE of 4B messa= ges either happened or didn't.

Brandon
--20cf3071c70c28d8f204caa2d943-- From prvs=76176b23c5=zordogh@rim.com Thu Sep 27 06:31: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 2228C21F8526 for ; Thu, 27 Sep 2012 06:31:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.053 X-Spam-Level: X-Spam-Status: No, score=-5.053 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] 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 gKyd--YAwWuq for ; Thu, 27 Sep 2012 06:31:05 -0700 (PDT) Received: from mhs061cnc.rim.net (mhs061cnc.rim.net [208.65.73.35]) by ietfa.amsl.com (Postfix) with ESMTP id 5330D21F8512 for ; Thu, 27 Sep 2012 06:31:05 -0700 (PDT) X-AuditID: 0a412830-b7fab6d000006b80-9e-506455182600 Received: from XCT101CNC.rim.net (xct101cnc.rim.net [10.65.161.201]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client did not present a certificate) by mhs061cnc.rim.net (SBG) with SMTP id 03.56.27520.81554605; Thu, 27 Sep 2012 13:31:04 +0000 (GMT) Received: from XCT109CNC.rim.net (10.65.161.209) by XCT101CNC.rim.net (10.65.161.201) with Microsoft SMTP Server (TLS) id 14.2.318.1; Thu, 27 Sep 2012 09:31:04 -0400 Received: from XMB163CNC.rim.net ([fe80::5805:6acc:b23a:e0a6]) by XCT109CNC.rim.net ([::1]) with mapi id 14.02.0318.001; Thu, 27 Sep 2012 09:31:03 -0400 From: Zoltan Ordogh To: Barry Leiba , Timo Sirainen Thread-Topic: [imapext] MOVE - A few late comments Thread-Index: Ac2bUv89gx2B1v8/TlWM3MMXzdiZvAAJXJ+AACAjfNAACuFegAAATHEAAAjhUgAAA27fAAAA2sAAAAA7TwAAFb/eUA== Date: Thu, 27 Sep 2012 13:31:03 +0000 Message-ID: <1DE983233DBBEB4A81F18FABD8208D7623138230@XMB163CNC.rim.net> References: <1DE983233DBBEB4A81F18FABD8208D762312F4F7@XMB163CNC.rim.net> <1348602587.18365.140661132619417.766B1A99@webmail.messagingengine.com> <1DE983233DBBEB4A81F18FABD8208D762312F76B@XMB163CNC.rim.net> <1348692262.28413.140661133130989.6CCAE683@webmail.messagingengine.com> <50638030.60505@computer.org> <5063877A.1090609@computer.org> In-Reply-To: <5063877A.1090609@computer.org> Accept-Language: en-US, en-CA Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.160.248] Content-Type: text/plain; charset="iso-8859-1" content-transfer-encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrHKsWRmVeSWpSXmKPExsXC5bjwpK5EaEqAwcwzChaHFl9itTi3dyqb xeNZXBZ727cyO7B4tKzqZfbYeeoAm8eSJT+ZPA5/XcgSwBLVwGiTlFhSFpyZnqdvZ5OYl5df kliSqpCSWpxsq+STmp6YoxBQlFmWmFyp4JJZnJyTmJmbWqSkkJliq2SipFCQk5icmpuaV2Kr lFhQkJqXomTHpYABbIDKMvMUUvOS81My89JtlTyD/XUtLEwtdQ2V7HQTOnkyjnWcYi64IlAx cdc6lgbG6bxdjJwcEgImEgs/zGSGsMUkLtxbz9bFyMUhJNDHJPHx+F8WCGclo8TWSSfZIZw5 jBKvbkwGcjg42ARUJeZcjQXpFhFwlbi5dx8riM0s4CPR/vMlG0iJsIChxLNfuSCmiICRROOP SIjqLIme3rNgFSxAQ+4dKgQJ8wp4SPyceRRq0UwWiZ93V7KDJDgFdCS2HFvDCGIzCshKrJ2z EmqTuMStJ/OZIO4XkFiy5zzUL6ISLx//Y4WwFSXmz73EBlGvJ3Fj6hQoW1ti2cLXzBCLBSVO znzCAmILCchIPJ9yiX0Co8QsJCtmIWmfhaR9FpL2BYwsqxgFczOKDcwMk/OS9Yoyc/XyUks2 MYJTj4bBDsb37y0OMQpwMCrx8Gp6pQQIsSaWFVfmHmKU4GBWEuGNUgUK8aYkVlalFuXHF5Xm pBYfYrQAhtBEZinu5HxgWswriTc2MEDhKInz/j6XGCAkkA5MVNmpqQWpRTCtTBycIKO5pESK gekmtSixtCQjHpQU44uBaVGqgfHgws2Ti/efN6lrOWd/IPmy6t8fpmzm//V8n5hlnpGZcb0p 1cXwmE7mP2PpmGnqx8UtV8jeea9/bnXFzuS+UlUz/fjAok6ljJxDQkor6meuvDpBRoGhcD2T 8I5lHnaXZn5sPfgmZ/eByUt1H64vjfbnO6dpdpilMifj5uXrTPbTuvqmP9CoZlZiKc5INNRi LipOBABgjBXVcQMAAA== Cc: Bron Gondwana , "imapext@ietf.org" Subject: Re: [imapext] MOVE - A few late comments 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, 27 Sep 2012 13:31:06 -0000 > -----Original Message----- > From: Barry Leiba [mailto:barryleiba@gmail.com] On Behalf Of Barry Leiba > Sent: Wednesday, September 26, 2012 18:54 > To: Timo Sirainen > Cc: Bron Gondwana; Zoltan Ordogh; imapext@ietf.org > Subject: Re: [imapext] MOVE - A few late comments > > > > For each individual message ok. But should all the messages be either > moved or none moved? Mainly should it fail and abort if some of the > messages were already expunged? COPY is defined to either copy all or > nothing. My MOVE implementation also moves all or nothing. But some > people wanted to use rename() and such that would make reverting in the > middle difficult. > I'm OK with saying that the action for each message must be well defined, > but allow for a group MOVE to fail in the middle. We should verify the > consensus on that point, though. > [Z=D6r] I also think it's ok to fail in the middle of MOVE, but the last mes= sage - when the failure occurred - should stay the way it was before the fai= lure. I say it's ok because I don't think the MOVE command is likely to fail in th= e middle. It is likely to fail at the first message: - permission problems - destination mailbox does not exist - first message does not exist I guess it can fail in the middle when: - a large message is encountered that triggers quota limit - though this ca= n be countered. - an extension of COPY/STORE/EXPUNGE triggers an error - a server error occurs (not related to the command itself but something th= at forces the command to be stopped). I do have a question however about a likely scenario: Is it considered an error if a message that was requested to be moved no lon= ger exists by the time it is about to be moved? For example. C: MOVE 1:2000 test The server begins moving the messages one by one, starting from the end or t= he beginning. In the meantime, another client deletes message 666. Would the MOVE command that is in progress on the server stop with an error= at message 666 or would the server just skip it? IMHO, it could skip it without an error. Thank you! --------------------------------------------------------------------- This transmission (including any attachments) may contain confidential infor= mation, privileged material (including material protected by the solicitor-c= lient or other applicable privileges), or constitute non-public information.= Any use of this information by anyone other than the intended recipient is= prohibited. If you have received this transmission in error, please immedia= tely reply to the sender and delete this information from your system. Use,= dissemination, distribution, or reproduction of this transmission by uninte= nded recipients is not authorized and may be unlawful. From brong@fastmail.fm Thu Sep 27 06:37: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 89CC721F84EB for ; Thu, 27 Sep 2012 06:37:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.509 X-Spam-Level: X-Spam-Status: No, score=-3.509 tagged_above=-999 required=5 tests=[AWL=0.090, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h2oI-pSdC4SS for ; Thu, 27 Sep 2012 06:37:51 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) by ietfa.amsl.com (Postfix) with ESMTP id EE77821F851A for ; Thu, 27 Sep 2012 06:37:50 -0700 (PDT) Received: from compute2.internal (compute2.nyi.mail.srv.osa [10.202.2.42]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id 105CE20416; Thu, 27 Sep 2012 09:37:50 -0400 (EDT) Received: from web2.nyi.mail.srv.osa ([10.202.2.212]) by compute2.internal (MEProxy); Thu, 27 Sep 2012 09:37:50 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=fastmail.fm; h= message-id:from:to:cc:mime-version:content-transfer-encoding :content-type:in-reply-to:references:subject:date; s=mesmtp; bh= xB3rn0lCejGv2+NyHhN9Lr1IuYs=; b=H8YdjNdwyvbB8TktyldXsRj6jDmeplOi pb6C7zKN9+urbqyaK/du8rzRptLDPUpTzjwwWLTsWcRWYIWSbwxyYhRT15vaI+hd AqRamHix3l36xt82jvXcrOhGMban0SqV1hiNRAJpIjyypNQkXOsePLR83g5hcxr0 fDafetZGJrA= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=message-id:from:to:cc:mime-version :content-transfer-encoding:content-type:in-reply-to:references :subject:date; s=smtpout; bh=xB3rn0lCejGv2+NyHhN9Lr1IuYs=; b=gd3 p43cHSOXbs9/nfW7lvUm/DOez9lcUVyGLoVkeaoF8r96c3wCE6xYieKVLUHmDtkM cDpMmle5Fi2DDjuTSAfop20y0M/N5Sp/Vd3gPxfySbDzPO535zA8OEZqTt9tszHj tyetdQ/7gBooMBScNTJRgfXbFbWomWtCF03gnStg= Received: by web2.nyi.mail.srv.osa (Postfix, from userid 99) id D71C45C2E8B; Thu, 27 Sep 2012 09:37:49 -0400 (EDT) Message-Id: <1348753069.9237.140661133431653.5403077F@webmail.messagingengine.com> X-Sasl-Enc: 2wgRcqea+WHNUR3OAIeezvPFfpzkdFnPZGZC6nG8VlGI 1348753069 From: Bron Gondwana To: Zoltan Ordogh , Barry Leiba , Timo Sirainen MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain X-Mailer: MessagingEngine.com Webmail Interface In-Reply-To: <1DE983233DBBEB4A81F18FABD8208D7623138230@XMB163CNC.rim.net> References: <1DE983233DBBEB4A81F18FABD8208D762312F4F7@XMB163CNC.rim.net> <1348602587.18365.140661132619417.766B1A99@webmail.messagingengine.com> <1DE983233DBBEB4A81F18FABD8208D762312F76B@XMB163CNC.rim.net> <1348692262.28413.140661133130989.6CCAE683@webmail.messagingengine.com> <50638030.60505@computer.org> <5063877A.1090609@computer.org> <1DE983233DBBEB4A81F18FABD8208D7623138230@XMB163CNC.rim.net> Date: Thu, 27 Sep 2012 15:37:49 +0200 Cc: "imapext@ietf.org" Subject: Re: [imapext] MOVE - A few late comments 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, 27 Sep 2012 13:37:51 -0000 On Thu, Sep 27, 2012, at 03:31 PM, Zoltan Ordogh wrote: > I do have a question however about a likely scenario: > Is it considered an error if a message that was requested to be moved no longer exists by the time it is about to be moved? > For example. > C: MOVE 1:2000 test > The server begins moving the messages one by one, starting from the end or the beginning. > In the meantime, another client deletes message 666. > Would the MOVE command that is in progress on the server stop with an error at message 666 or would the server just skip it? > IMHO, it could skip it without an error. Cyrus would hold a lock, so it doesn't matter - but if the message doesn't exist at the start, it just doesn't move it (possible if it was expunged in another parallel session) And that's fine. Bron. -- Bron Gondwana brong@fastmail.fm