Re: [imap5] ERASE command as part of MOVE

Barry Leiba <barryleiba@computer.org> Sat, 02 June 2012 01:55 UTC

Return-Path: <barryleiba.mailing.lists@gmail.com>
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 3188F21F8857 for <imap5@ietfa.amsl.com>; Fri, 1 Jun 2012 18:55:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.005
X-Spam-Level:
X-Spam-Status: No, score=-103.005 tagged_above=-999 required=5 tests=[AWL=-0.028, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GpoDFhKhMp1n for <imap5@ietfa.amsl.com>; Fri, 1 Jun 2012 18:55:26 -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 95C8721F85E5 for <imap5@ietf.org>; Fri, 1 Jun 2012 18:54:55 -0700 (PDT)
Received: by lagv3 with SMTP id v3so2093415lag.31 for <imap5@ietf.org>; Fri, 01 Jun 2012 18:54:54 -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=B5CwJLCW2J+/tPYrlF6eGNv7k9sbv4Q/1N1w3nsF+Qk=; b=SN59U+UfMc73rEK077v9Qcoxohzaz6leYVtR0Cy6XRa2+oCZ9EJjHmuPnYWmv2U60h h8sTk2VTd+0CkRgFHsB75k6+9CR5gIhUql0lHn/T/zmHkaIz55wQRR/XH4bt8VXnFkic F9sGliyH7QErfPdOA/nSNtc5jP5rbPRyDCRli73nZ8F1bFf/zGLwUkim2DLz7wlzWpIb tVwFMIrej/dYmq7faCz2aWqH18LDjN1TvbLqUR8ndY1sVCVP9/iX26ylrufW0RT70bC1 HRYxiC3lmG9Hxu5fw+sGB15b0njfBWG4m+PiOzdtP/ak/5VOTOhe+KOOprybuURPMwQ2 3yOw==
MIME-Version: 1.0
Received: by 10.152.113.199 with SMTP id ja7mr5089660lab.10.1338602094554; Fri, 01 Jun 2012 18:54:54 -0700 (PDT)
Sender: barryleiba.mailing.lists@gmail.com
Received: by 10.112.48.104 with HTTP; Fri, 1 Jun 2012 18:54:54 -0700 (PDT)
In-Reply-To: <20120601222311.GB598@launde.brong.net>
References: <20120601222311.GB598@launde.brong.net>
Date: Fri, 01 Jun 2012 21:54:54 -0400
X-Google-Sender-Auth: hirq7OABzqm6hbbHg_QBMkkqvDQ
Message-ID: <CAC4RtVBrM2fY7GGM1s-NRhKMU48NSOMMtkMVqnQ_zbbLnBtM_A@mail.gmail.com>
From: Barry Leiba <barryleiba@computer.org>
To: Bron Gondwana <brong@fastmail.fm>
Content-Type: text/plain; charset="ISO-8859-1"
Cc: Arnt Gulbrandsen <arnt@gulbrandsen.priv.no>, imap5@ietf.org
Subject: Re: [imap5] ERASE command as part of MOVE
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: Sat, 02 Jun 2012 01:55:27 -0000

> But it would be very useful to have the second half of that
> available as a separate command in its own right, "ERASE"
...
> So Arnt, does it make sense to either propose both commands as
> part of this draft and implement one in terms of the other, or
> to do an ERASE first and then a separate MOVE referencing ERASE?

As Timo says, you can pipeline the STORE and UID EXPUNGE.  Unless you
can come up with some reason that an atomic ERASE command would save
something significant in the message store -- something I can't
imagine to be the case -- there's nowhere near the use for this as
there is for MOVE (where it's not just the round trips that are saved,
because it allows message-store optimization in some cases).

But more to the point: you'll note that the proposed charter is VERY
tight on this, and will not be changed... there is exactly ONE thing
chartered here, and an ERASE command is not it.  This is quite
intentional, to head off tangents and feature creep, and to keep us to
the thing that's being demanded by, we're told, a significant number
of implementors.

Please do not try to add anything more to this very tightly focused effort.

Barry, Applications AD