IETF Logo Mail Archive

Re: [imap5] Feature set? - was Re: Designing a new replacement protocol for IMAP

Dave Cridland <dave@cridland.net> Fri, 24 February 2012 23:12 UTC

Return-Path: <dave@cridland.net>
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 5378821F8620 for <imap5@ietfa.amsl.com>; Fri, 24 Feb 2012 15:12:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.445
X-Spam-Level:
X-Spam-Status: No, score=-2.445 tagged_above=-999 required=5 tests=[AWL=0.154, BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sJI17Ww0MtaG for <imap5@ietfa.amsl.com>; Fri, 24 Feb 2012 15:12:53 -0800 (PST)
Received: from peirce.dave.cridland.net (peirce.dave.cridland.net [IPv6:2001:470:1f09:882:2e0:81ff:fe29:d16a]) by ietfa.amsl.com (Postfix) with ESMTP id 598AE21F863D for <imap5@ietf.org>; Fri, 24 Feb 2012 15:12:53 -0800 (PST)
Received: from localhost (peirce.dave.cridland.net [127.0.0.1]) by peirce.dave.cridland.net (Postfix) with ESMTP id 479181168087; Fri, 24 Feb 2012 23:12:47 +0000 (GMT)
X-Virus-Scanned: Debian amavisd-new at peirce.dave.cridland.net
Received: from peirce.dave.cridland.net ([127.0.0.1]) by localhost (peirce.dave.cridland.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id whB7sXplrVK3; Fri, 24 Feb 2012 23:12:41 +0000 (GMT)
Received: from puncture (puncture.dave.cridland.net [IPv6:2001:470:1f09:882:221:85ff:fe3f:1696]) by peirce.dave.cridland.net (Postfix) with ESMTPA id A357F1168067; Fri, 24 Feb 2012 23:12:40 +0000 (GMT)
References: <3077.1329391344.173214@puncture> <4F3CEB35.9080200@qbik.com> <1329394296.953.140661037317197@webmail.messagingengine.com> <4F3CFD35.10501@qbik.com> <alpine.LSU.2.00.1202161626400.30682@hermes-2.csi.cam.ac.uk> <4F3D6E57.8010301@qbik.com> <alpine.LSU.2.00.1202171127330.30682@hermes-2.csi.cam.ac.uk> <4F3F4F8F.3040601@qbik.com> <1329550573.30138.140661038121885@webmail.messagingengine.com> <alpine.LSU.2.00.1202191832430.12769@hermes-2.csi.cam.ac.uk> <20120219192604.GA11323@launde.brong.net> <alpine.LSU.2.00.1202201048480.31357@hermes-2.csi.cam.ac.uk> <4F465269.1040901@flaska.net> <4F465EBC.7090206@att.com> <16456.1330038954.623322@puncture> <CABa8R6vqMQYRJp-3zpA-GwzKfGTToXTbiGFssHF+375qdRcmYw@mail.gmail.com> <4F4751C0.20709@gulbrandsen.priv.no> <CABa8R6tFA2DFW6JMzASDf1Nhchs+ZZGd0bC9Qtv1c3DtyeSHKQ@mail.gmail.com> <4F47F310.3040203@qbik.com> <CABa8R6vMAF3gB0OH9dGsrPLKVbDqnWM+njmHg6PDnNmGG7wezg@mail.gmail.com>
In-Reply-To: <CABa8R6vMAF3gB0OH9dGsrPLKVbDqnWM+njmHg6PDnNmGG7wezg@mail.gmail.com>
MIME-Version: 1.0
Message-Id: <16456.1330125160.642317@puncture>
Date: Fri, 24 Feb 2012 23:12:40 +0000
From: Dave Cridland <dave@cridland.net>
To: Brandon Long <blong@google.com>, "Discussion on drastically slimming-down IMAP." <imap5@ietf.org>, Arnt Gulbrandsen <arnt@gulbrandsen.priv.no>, Adrien de Croy <adrien@qbik.com>
Content-Type: text/plain; delsp="yes"; charset="us-ascii"; format="flowed"
Subject: Re: [imap5] Feature set? - was Re: Designing a new replacement protocol for IMAP
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: Fri, 24 Feb 2012 23:12:54 -0000

On Fri Feb 24 21:23:08 2012, Brandon Long wrote:
> That was in the P-IMAP proposal, which I assume means it was  
> discussed
> in lemonade, anyone recall why it didn't go anywhere?
> 
> 
It forces scalability to be per-device, rather than per-user.

It generally struck me as fairly fragile, too - typically, the  
server's going to erase older tokens after a while, and limit the  
numbers, and there's no fallback at all.


> Granted, with qresync/condstore, session maintenance probably isn't  
> as
> important.

Right, and QRESYNC doesn't require *any* state beyond CONDSTORE's  
64-bits per message and per folder.

Dave.
-- 
Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@dave.cridland.net
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade

v2.23.0 | Report a Bug | By Email