[imap5] Comments on draft-gulbrandsen-imap-move-01
Cyrus Daboo <cyrus@daboo.name> Thu, 31 May 2012 14:20 UTC
Return-Path: <cyrus@daboo.name>
X-Original-To: imap5@ietfa.amsl.com
Delivered-To: imap5@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C9CE21F85A4 for <imap5@ietfa.amsl.com>; Thu, 31 May 2012 07:20:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.901
X-Spam-Level:
X-Spam-Status: No, score=-101.901 tagged_above=-999 required=5 tests=[AWL=-0.698, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2ITOQYAJz8KZ for <imap5@ietfa.amsl.com>; Thu, 31 May 2012 07:20:21 -0700 (PDT)
Received: from daboo.name (daboo.name [173.13.55.49]) by ietfa.amsl.com (Postfix) with ESMTP id 14AD321F8598 for <imap5@ietf.org>; Thu, 31 May 2012 07:20:21 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by daboo.name (Postfix) with ESMTP id 905302841707 for <imap5@ietf.org>; Thu, 31 May 2012 10:20:20 -0400 (EDT)
X-Virus-Scanned: amavisd-new at daboo.name
Received: from daboo.name ([127.0.0.1]) by localhost (daboo.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XyP6gqg1aWIQ for <imap5@ietf.org>; Thu, 31 May 2012 10:20:16 -0400 (EDT)
Received: from caldav.corp.apple.com (unknown [17.45.162.46]) by daboo.name (Postfix) with ESMTPSA id C347D28416FA for <imap5@ietf.org>; Thu, 31 May 2012 10:20:15 -0400 (EDT)
Date: Thu, 31 May 2012 10:20:12 -0400
From: Cyrus Daboo <cyrus@daboo.name>
To: imap5@ietf.org
Message-ID: <7EF71BCD5999FCCF89A1E22D@caldav.corp.apple.com>
X-Mailer: Mulberry/4.1.0a3 (Mac OS X)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline; size="2840"
Subject: [imap5] Comments on draft-gulbrandsen-imap-move-01
X-BeenThere: imap5@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Discussion on drastically slimming-down IMAP." <imap5.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/imap5>, <mailto:imap5-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/imap5>
List-Post: <mailto:imap5@ietf.org>
List-Help: <mailto:imap5-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/imap5>, <mailto:imap5-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 31 May 2012 14:20:21 -0000
Hi, Some comments on the move extension draft: - §2: what is the problem with sequence MOVE and EXPUNGE? For what it is worth Mulberry has always preferred sequence over uids when online (it uses UID commands when doing disconnected play back). That said, mapping to uids is no big deal (and should not be a big deal for any other client that might use sequence in normal operation). - §2: "atomically" - I would prefer not to use the term "atomic" given that we are allowing partial failures (i.e., some messages might not be moved, whilst others are). So in the first paragraph I suggest changing "atomically" to "using a single command". - §3: This needs a 3501-like "formal" definition with Arguments:, Responses:, Results: etc. It should use the same text for describing preservation of flags (see note below) and internal date. We need to decide whether the \Recent flag is set like COPY (probably should be). Also, the [TRYCREATE] behavior from COPY should be re-used. Should probably note that this command is only valid in selected state (or include a comment to that effect in the formal syntax which 3501 does for the command-select syntax element). - §3, ¶2: "UID EXPUNGE" - need a reference to the UIDPLUS extension. - §3, ¶4: states that \Deleted must not be set in the target mailbox. But what if the messages being moved already had \Deleted set prior to the move? Shouldn't we just state that the flag/keywords prior to the move must be set on the messages in the target mailbox? - §3: As already mentioned, EXPUNGE responses need to be present. Might be worth pointing out that there could be a * EXPUNGE for a message not being moved, but which got expunged in another session. Actually, more complicated is the case where a message being moved was expunged in another session - presumably that message is not moved? Yet it would get reported in a * EXPUNGE, but not be part of the COPYUID set. - §3: Might want to make it clear that * FETCH FLAGS is NOT sent if moved messages have \Deleted added as part of the "internal" server implementation of move. - §3: Example: change "@S:" to "S:". - §3: COPYUID response in the argument is wrong - it should have three values: destination mailbox UIDVALIDITY, set of uids from source mailbox, set of uids in destination mailbox. Current example only shows one set of uids. - §4: whilst no one may implement it, there still ought to be a reference to the interaction with ANNOTATE. ANNOTATE §4.6 has detailed text on the interaction with COPY and something similar is needed for MOVE. - §6: "command" is not the right syntax element to extend. I would suggest defining a uidmove element and then use that to extend the 3501 uid element: uidmove = "UID MOVE" SP set SP mailbox uid =/ uidmove -- Cyrus Daboo
- [imap5] Comments on draft-gulbrandsen-imap-move-01 Cyrus Daboo
- Re: [imap5] Comments on draft-gulbrandsen-imap-mo… Bron Gondwana
- Re: [imap5] Comments on draft-gulbrandsen-imap-mo… Timo Sirainen
- Re: [imap5] Comments on draft-gulbrandsen-imap-mo… Bron Gondwana
- Re: [imap5] Comments on draft-gulbrandsen-imap-mo… Arnt Gulbrandsen
- Re: [imap5] Comments on draft-gulbrandsen-imap-mo… Barry Leiba