From internet-drafts@ietf.org Mon Jul 1 05:59:16 2013 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 9CDF011E8A5D; Mon, 1 Jul 2013 05:59:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.509 X-Spam-Level: X-Spam-Status: No, score=-102.509 tagged_above=-999 required=5 tests=[AWL=0.091, BAYES_00=-2.599, NO_RELAYS=-0.001, 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 XOLJCaYWODJ3; Mon, 1 Jul 2013 05:59:16 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E502A21F85F4; Mon, 1 Jul 2013 05:51:33 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.51.p2 Message-ID: <20130701125133.26389.30092.idtracker@ietfa.amsl.com> Date: Mon, 01 Jul 2013 05:51:33 -0700 Cc: imapext@ietf.org Subject: [imapext] I-D Action: draft-ietf-qresync-rfc4551bis-02.txt X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Jul 2013 12:59:16 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the IMAP QRESYNC Extension Working Group of t= he IETF. Title : IMAP Extension for Conditional STORE Operation or Quick = Flag Changes Resynchronization Author(s) : Alexey Melnikov Filename : draft-ietf-qresync-rfc4551bis-02.txt Pages : 25 Date : 2013-07-01 Abstract: Often, multiple IMAP (RFC 3501) clients need to coordinate changes to a common IMAP mailbox. Examples include different clients working on behalf of the same user, and multiple users accessing shared mailboxes. These clients need a mechanism to synchronize state changes for messages within the mailbox. They must be able to guarantee that only one client can change message state (e.g., message flags) at any time. An example of such an application is use of an IMAP mailbox as a message queue with multiple dequeueing clients. The Conditional Store facility provides a protected update mechanism for message state information that can detect and resolve conflicts between multiple writing mail clients. The Conditional Store facility also allows a client to quickly resynchronize mailbox flag changes. This document defines an extension to IMAP (RFC 3501). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-qresync-rfc4551bis There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-qresync-rfc4551bis-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-qresync-rfc4551bis-02 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From internet-drafts@ietf.org Mon Jul 1 06:12:03 2013 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 0F74B11E8314; Mon, 1 Jul 2013 06:12:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.512 X-Spam-Level: X-Spam-Status: No, score=-102.512 tagged_above=-999 required=5 tests=[AWL=0.088, BAYES_00=-2.599, NO_RELAYS=-0.001, 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 8C3zA1xSs5+z; Mon, 1 Jul 2013 06:12:02 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 84A3911E83F0; Mon, 1 Jul 2013 06:01:11 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.51.p2 Message-ID: <20130701130111.10270.86651.idtracker@ietfa.amsl.com> Date: Mon, 01 Jul 2013 06:01:11 -0700 Cc: imapext@ietf.org Subject: [imapext] I-D Action: draft-ietf-qresync-rfc5162bis-01.txt X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Jul 2013 13:12:03 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the IMAP QRESYNC Extension Working Group of t= he IETF. Title : IMAP4 Extensions for Quick Mailbox Resynchronization Author(s) : Alexey Melnikov Dave Cridland Filename : draft-ietf-qresync-rfc5162bis-01.txt Pages : 24 Date : 2013-07-01 Abstract: This document defines an IMAP4 extension, which gives an IMAP client the ability to quickly resynchronize any previously opened mailbox as part of the SELECT command, without the need for server-side state or additional client round-trips. This extension also introduces a new response that allows for a more compact representation of a list of expunged messages (and always includes the Unique Identifiers (UIDs) expunged). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-qresync-rfc5162bis There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-qresync-rfc5162bis-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-qresync-rfc5162bis-01 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From dave@cridland.net Tue Jul 2 00:35:06 2013 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 D553521F9B66 for ; Tue, 2 Jul 2013 00:35:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] 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 S3bqUApkHS7c for ; Tue, 2 Jul 2013 00:35:05 -0700 (PDT) Received: from mail-oa0-x22b.google.com (mail-oa0-x22b.google.com [IPv6:2607:f8b0:4003:c02::22b]) by ietfa.amsl.com (Postfix) with ESMTP id D0EF611E82F0 for ; Tue, 2 Jul 2013 00:35:04 -0700 (PDT) Received: by mail-oa0-f43.google.com with SMTP id i7so6101729oag.30 for ; Tue, 02 Jul 2013 00:35:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cridland.net; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=1CPAamzcLPbFeKHXEiYVxI5QDLkfmhRuRrrYtJ6NEkg=; b=b4k2suC60OSVIjPd4B4x02qBSAeMNuF1bhLEuF0/vZKe4yuGNfFVLgIgsNM8gO3Vsl X437cnmAHPUmzJonuuG6rrDR9Rw44wdq9q9U+0oMutFk6OFT5R0v05dFonb9NgmUlXEA vY3sbs5OnzSleKNHP+fRJkCjXWo/tKdq90smQ= 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 :content-type:x-gm-message-state; bh=1CPAamzcLPbFeKHXEiYVxI5QDLkfmhRuRrrYtJ6NEkg=; b=N9Ng701FcN4e6Obo3WNH41z0fojMk3GbkeNrMu/9T3T/qiSeDiN6zo8AUcZAQF21im T0dE4vHYnrlsuIo5+XJVh2GdDQckIKQZcwuTNSzD/x8A07f4AvxsbQVAIdFSTFSkaif2 GzMLHE0dLeavKM8FYyOQsEjX49A9Q4unXb9U7Ri7VETMKYQXAV9LkSNbsZTI8jEaEeET FIrWuilAmvrFGMrRlRqB3Smaud2Q2778z02iblGgSc5k1NS9hGCLfc+EH6DkY6XauLzf SuoKQX5SrGpWRrspAa2NLdfhRBe7U7YE1xKNkYyOeInOyYCivOJdII0w/b4s9YUIN+Lw iB/w== MIME-Version: 1.0 X-Received: by 10.60.39.193 with SMTP id r1mr11340358oek.40.1372750503262; Tue, 02 Jul 2013 00:35:03 -0700 (PDT) Received: by 10.60.139.212 with HTTP; Tue, 2 Jul 2013 00:35:03 -0700 (PDT) In-Reply-To: <20130701125133.26389.30092.idtracker@ietfa.amsl.com> References: <20130701125133.26389.30092.idtracker@ietfa.amsl.com> Date: Tue, 2 Jul 2013 08:35:03 +0100 Message-ID: From: Dave Cridland To: "imapext@ietf.org" Content-Type: multipart/alternative; boundary=089e0149cc461cd62904e082626e X-Gm-Message-State: ALoCoQk7H12/ClcHZp65eMkAl8ttJyKO8cqurJ0WYyd2gM1SEgrcmKqeWrw1idKJe/sW7eLrPq8m Subject: Re: [imapext] I-D Action: draft-ietf-qresync-rfc4551bis-02.txt X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jul 2013 07:35:07 -0000 --089e0149cc461cd62904e082626e Content-Type: text/plain; charset=ISO-8859-1 Alexey, Can you run us through the changes in these two? On Mon, Jul 1, 2013 at 1:51 PM, wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the IMAP QRESYNC Extension Working Group of > the IETF. > > Title : IMAP Extension for Conditional STORE Operation > or Quick Flag Changes Resynchronization > Author(s) : Alexey Melnikov > Filename : draft-ietf-qresync-rfc4551bis-02.txt > Pages : 25 > Date : 2013-07-01 > > Abstract: > Often, multiple IMAP (RFC 3501) clients need to coordinate changes to > a common IMAP mailbox. Examples include different clients working on > behalf of the same user, and multiple users accessing shared > mailboxes. These clients need a mechanism to synchronize state > changes for messages within the mailbox. They must be able to > guarantee that only one client can change message state (e.g., > message flags) at any time. An example of such an application is use > of an IMAP mailbox as a message queue with multiple dequeueing > clients. > > The Conditional Store facility provides a protected update mechanism > for message state information that can detect and resolve conflicts > between multiple writing mail clients. > > The Conditional Store facility also allows a client to quickly > resynchronize mailbox flag changes. > > This document defines an extension to IMAP (RFC 3501). > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-qresync-rfc4551bis > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-qresync-rfc4551bis-02 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-qresync-rfc4551bis-02 > > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > imapext mailing list > imapext@ietf.org > https://www.ietf.org/mailman/listinfo/imapext > --089e0149cc461cd62904e082626e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Alexey,

Can you run us through the chan= ges in these two?


On Mon, Jul 1, 2013 at 1:51 PM, <internet-drafts@= ietf.org> wrote:

A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
=A0This draft is a work item of the IMAP QRESYNC Extension Working Group of= the IETF.

=A0 =A0 =A0 =A0 Title =A0 =A0 =A0 =A0 =A0 : IMAP Extension for Conditional = STORE Operation or Quick Flag Changes Resynchronization
=A0 =A0 =A0 =A0 Author(s) =A0 =A0 =A0 : Alexey Melnikov
=A0 =A0 =A0 =A0 Filename =A0 =A0 =A0 =A0: draft-ietf-qresync-rfc4551bis-02.= txt
=A0 =A0 =A0 =A0 Pages =A0 =A0 =A0 =A0 =A0 : 25
=A0 =A0 =A0 =A0 Date =A0 =A0 =A0 =A0 =A0 =A0: 2013-07-01

Abstract:
=A0 =A0Often, multiple IMAP (RFC 3501) clients need to coordinate changes t= o
=A0 =A0a common IMAP mailbox. =A0Examples include different clients working= on
=A0 =A0behalf of the same user, and multiple users accessing shared
=A0 =A0mailboxes. =A0These clients need a mechanism to synchronize state =A0 =A0changes for messages within the mailbox. =A0They must be able to
=A0 =A0guarantee that only one client can change message state (e.g.,
=A0 =A0message flags) at any time. =A0An example of such an application is = use
=A0 =A0of an IMAP mailbox as a message queue with multiple dequeueing
=A0 =A0clients.

=A0 =A0The Conditional Store facility provides a protected update mechanism=
=A0 =A0for message state information that can detect and resolve conflicts<= br> =A0 =A0between multiple writing mail clients.

=A0 =A0The Conditional Store facility also allows a client to quickly
=A0 =A0resynchronize mailbox flag changes.

=A0 =A0This document defines an extension to IMAP (RFC 3501).


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-qresync-rfc45= 51bis

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-qresync-rfc4551bis-02<= /a>

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-qresyn= c-rfc4551bis-02


Internet-Drafts are also available by anonymous FTP at:
ftp://ftp= .ietf.org/internet-drafts/

_______________________________________________
imapext mailing list
imapext@ietf.org
https://www.ietf.org/mailman/listinfo/imapext

--089e0149cc461cd62904e082626e-- From alexey.melnikov@isode.com Tue Jul 2 02:59:00 2013 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 6CE8511E8452 for ; Tue, 2 Jul 2013 02:59:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PSQxMdmkB3pZ for ; Tue, 2 Jul 2013 02:58:56 -0700 (PDT) Received: from statler.isode.com (statler.isode.com [62.3.217.254]) by ietfa.amsl.com (Postfix) with ESMTP id 0B24911E8472 for ; Tue, 2 Jul 2013 02:58:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1372759131; d=isode.com; s=selector; i=@isode.com; bh=Ji5OZOUV60gCkH/aQ7uXOaBY4docLDt+1/86i+9/+/w=; 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=fNZr2RLfJYERRAp9M3WyoQ0hui5qi+Q1wvazA1TV2YMy/C2dfOHlEXgjfAiuHPhq7xdIoX gTXMoLmWiPPjdbzWXm6kb6f4Mq2bAgW59RWzQ11pDt9SQjSu4C+HhodDc1ZeeHyjRZcLzW W0BAnDEPv3b0mVVPO3xNcZbWAulGYJY=; 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, 2 Jul 2013 10:58:51 +0100 Message-ID: <51D2A492.5000200@isode.com> Date: Tue, 02 Jul 2013 10:59:46 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 To: "imapext@ietf.org" References: <20130701125133.26389.30092.idtracker@ietfa.amsl.com> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [imapext] Updated draft-ietf-qresync-rfc4551bis-02.txt and draft-ietf-qresync-rfc5162bis-01.txt X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jul 2013 09:59:00 -0000 On 02/07/2013 08:35, Dave Cridland wrote: > Alexey, > > Can you run us through the changes in these two? Changes to 4551bis: http://www.ietf.org/rfcdiff?url2=draft-ietf-qresync-rfc4551bis-02 Added "ENABLE CONDSTORE" to the list of CONDSTORE enabled commands. ([RFC5161] already said that, but I thought it would be a good idea to clarify this here.) Clarified that NOMODSEQ/HIGHESTMODSEQ Response Codes need to be returned on SELECT/EXAMINE whether or not the client issued a CONDSTORE enabling command. Corrected one internal reference I missed in the previous revision. Clarified that HIGHESTMODSEQ needs to be issued after a CONDSTORE enabling command, only if there is a mailbox selected. (This is probably obvious, but I though it wouldn't hurt.) Changes to 5162bis: http://www.ietf.org/rfcdiff?url2=draft-ietf-qresync-rfc5162bis-01 Clarified that ENABLE QRESYNC CONDSTORE and ENABLE CONDSTORE QRESYNC are equivalent. Changed the requirement to return VANISHED from SHOULD to MUST as per the mailing list discussion. The only exception is for mailboxes that return NOMODSEQ. From alexey.melnikov@isode.com Tue Jul 2 03:36:20 2013 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 6650F11E8476 for ; Tue, 2 Jul 2013 03:36:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jz3iNMFFD1f4 for ; Tue, 2 Jul 2013 03:36:19 -0700 (PDT) Received: from waldorf.isode.com (cl-125.lon-03.gb.sixxs.net [IPv6:2a00:14f0:e000:7c::2]) by ietfa.amsl.com (Postfix) with ESMTP id B712F11E846D for ; Tue, 2 Jul 2013 03:36:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1372761377; d=isode.com; s=selector; i=@isode.com; bh=PnIgUcoHhsA0gE7RNvPAXOZbmtlmLzt/w/a74cNvNBQ=; 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=rP5VjuIy5MeFMb/cv16OLzfkBZ4p35fWNVofCiIzbaupRpJoq5BGBEdioGc8Wvl/RpW9sM +cx3Y6a30vvIOCpBz5SHTH9hTHolrlWrh9CTM3D+crekEwU1J5vQBLVWYGqxuosqDu4Qd4 4jw8x8ow5SobCsXTXQF7iC1NhlzaD6U=; Received: from [172.16.1.29] (shiny.isode.com [62.3.217.250]) by waldorf.isode.com (submission channel) via TCP with ESMTPA id ; Tue, 2 Jul 2013 11:36:17 +0100 Message-ID: <51D2AD58.5020507@isode.com> Date: Tue, 02 Jul 2013 11:37:12 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 To: "imapext@ietf.org" References: <20130701125133.26389.30092.idtracker@ietfa.amsl.com> <51D2A492.5000200@isode.com> In-Reply-To: <51D2A492.5000200@isode.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [imapext] Updated draft-ietf-qresync-rfc4551bis-02.txt and draft-ietf-qresync-rfc5162bis-01.txt X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jul 2013 10:36:20 -0000 On 02/07/2013 10:59, Alexey Melnikov wrote: > Changes to 5162bis: > > http://www.ietf.org/rfcdiff?url2=draft-ietf-qresync-rfc5162bis-01 > > > Clarified that ENABLE QRESYNC CONDSTORE and ENABLE CONDSTORE QRESYNC > are equivalent. > > Changed the requirement to return VANISHED from SHOULD to MUST as per > the mailing > list discussion. The only exception is for mailboxes that return > NOMODSEQ. Except that I didn't make this change everywhere in the document... I will post -02 shortly to address this. From internet-drafts@ietf.org Tue Jul 2 06:54:54 2013 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 9CE8D21F9C87; Tue, 2 Jul 2013 06:54:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.475 X-Spam-Level: X-Spam-Status: No, score=-102.475 tagged_above=-999 required=5 tests=[AWL=0.125, BAYES_00=-2.599, NO_RELAYS=-0.001, 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 2DssMbr+Op1k; Tue, 2 Jul 2013 06:54:54 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CFBE21F99BA; Tue, 2 Jul 2013 06:54:54 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.51.p2 Message-ID: <20130702135454.3325.23598.idtracker@ietfa.amsl.com> Date: Tue, 02 Jul 2013 06:54:54 -0700 Cc: imapext@ietf.org Subject: [imapext] I-D Action: draft-ietf-qresync-rfc5162bis-02.txt X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jul 2013 13:54:54 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the IMAP QRESYNC Extension Working Group of t= he IETF. Title : IMAP4 Extensions for Quick Mailbox Resynchronization Author(s) : Alexey Melnikov Dave Cridland Filename : draft-ietf-qresync-rfc5162bis-02.txt Pages : 25 Date : 2013-07-02 Abstract: This document defines an IMAP4 extension, which gives an IMAP client the ability to quickly resynchronize any previously opened mailbox as part of the SELECT command, without the need for server-side state or additional client round-trips. This extension also introduces a new response that allows for a more compact representation of a list of expunged messages (and always includes the Unique Identifiers (UIDs) expunged). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-qresync-rfc5162bis There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-qresync-rfc5162bis-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-qresync-rfc5162bis-02 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From tss@iki.fi Tue Jul 2 10:02:34 2013 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 38A0811E80FA for ; Tue, 2 Jul 2013 10:02:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nZJN2J7jGl+r for ; Tue, 2 Jul 2013 10:02:28 -0700 (PDT) Received: from dovecot.org (dovecot.org [193.210.130.67]) by ietfa.amsl.com (Postfix) with ESMTP id 5077721F9CF8 for ; Tue, 2 Jul 2013 10:02:27 -0700 (PDT) Received: from [192.168.10.100] (cs181255018.pp.htv.fi [82.181.255.18]) by dovecot.org (Postfix) with ESMTP id 32A421AE8786 for ; Tue, 2 Jul 2013 20:02:26 +0300 (EEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Timo Sirainen In-Reply-To: <20130702135454.3325.23598.idtracker@ietfa.amsl.com> Date: Tue, 2 Jul 2013 20:02:25 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20130702135454.3325.23598.idtracker@ietfa.amsl.com> To: "imapext@ietf.org" X-Mailer: Apple Mail (2.1508) Subject: Re: [imapext] I-D Action: draft-ietf-qresync-rfc5162bis-02.txt X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jul 2013 17:02:34 -0000 > If at least one message got expunged and QRESYNC was enabled, > the server MUST send the updated per-mailbox modification sequence > using the HIGHESTMODSEQ response code (defined in [CONDSTORE]) in = the > tagged OK response. >=20 > Example: C: A202 EXPUNGE > S: * 3 EXPUNGE > S: * 3 EXPUNGE > S: * 5 EXPUNGE > S: * 8 EXPUNGE > S: A202 OK [HIGHESTMODSEQ 20010715194045319] expunged >=20 > Note: In this example the client hasn't enabled QRESYNC, so the > server is still using untagged EXPUNGE responses. Note that the > presence of HIGHESTMODSEQ response code is optional in this case. Since this is about implementing QRESYNC support, wouldn't it be easier = and less confusing to remove most of this text and simply use an example = using VANISHED? From alexey.melnikov@isode.com Wed Jul 3 06:26:22 2013 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 3B91721F9C93 for ; Wed, 3 Jul 2013 06:26:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pQcQcaUDf2iP for ; Wed, 3 Jul 2013 06:26:21 -0700 (PDT) Received: from waldorf.isode.com (cl-125.lon-03.gb.sixxs.net [IPv6:2a00:14f0:e000:7c::2]) by ietfa.amsl.com (Postfix) with ESMTP id 7E4F321F9C95 for ; Wed, 3 Jul 2013 06:26:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1372857979; d=isode.com; s=selector; i=@isode.com; bh=YG2YRF7Hnxjit7dWI1hAAjPYjIgAzX2yZ8bTCE7p2GE=; 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=nFQ/KRp1v52D4GWxHW6kqZO730vt8iqci+pyKO0pLxRkDQpoViqjsa353rCqljIUCCkhqe DFZpqzkKjfAxduLEs2d/frzV1K7xeaiEpLCPly9/ELCKQcMN0MX+H7pm5e9XNWB0KIvFYH OzkNcjC71NE0wPNW+hh3GTyEs9lQrSw=; Received: from [172.20.10.2] ((unknown) [212.183.128.235]) by waldorf.isode.com (submission channel) via TCP with ESMTPA id ; Wed, 3 Jul 2013 14:26:19 +0100 X-SMTP-Protocol-Errors: NORDNS Message-ID: <51D41E87.8080307@isode.com> Date: Wed, 03 Jul 2013 13:52:23 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 To: Timo Sirainen References: <20130702135454.3325.23598.idtracker@ietfa.amsl.com> 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] I-D Action: draft-ietf-qresync-rfc5162bis-02.txt X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jul 2013 13:26:22 -0000 On 02/07/2013 18:02, Timo Sirainen wrote: >> If at least one message got expunged and QRESYNC was enabled, >> the server MUST send the updated per-mailbox modification sequence >> using the HIGHESTMODSEQ response code (defined in [CONDSTORE]) in the >> tagged OK response. >> >> Example: C: A202 EXPUNGE >> S: * 3 EXPUNGE >> S: * 3 EXPUNGE >> S: * 5 EXPUNGE >> S: * 8 EXPUNGE >> S: A202 OK [HIGHESTMODSEQ 20010715194045319] expunged >> >> Note: In this example the client hasn't enabled QRESYNC, so the >> server is still using untagged EXPUNGE responses. Note that the >> presence of HIGHESTMODSEQ response code is optional in this case. > Since this is about implementing QRESYNC support, wouldn't it be easier and less confusing to remove most of this text and simply use an example using VANISHED? I was thinking about the section as being a complete replacement of the definition in RFC 3501. I think it is important to point out that there are some conditions when EXPUNGE responses will still be used. How about reversing the order of examples (and possibly some extra clarifying text)? From arnt@gulbrandsen.priv.no Wed Jul 3 06:56:27 2013 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 6664321F9C09 for ; Wed, 3 Jul 2013 06:56:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yWHoTG3obhT5 for ; Wed, 3 Jul 2013 06:56:27 -0700 (PDT) Received: from strange.aox.org (strange.aox.org [IPv6:2001:4d88:100c::1]) by ietfa.amsl.com (Postfix) with ESMTP id D18C811E81A9 for ; Wed, 3 Jul 2013 06:56:25 -0700 (PDT) Received: from fri.gulbrandsen.priv.no (localhost [127.0.0.1]) by strange.aox.org (Postfix) with ESMTP id 4D868FA009E; Wed, 3 Jul 2013 13:56:24 +0000 (UTC) Received: from arnt@gulbrandsen.priv.no by fri.gulbrandsen.priv.no (Archiveopteryx 3.1.4) with esmtpsa id 1372859782-3316-3312/11/9; Wed, 3 Jul 2013 13:56:22 +0000 Date: Wed, 3 Jul 2013 15:56:23 +0200 From: Arnt Gulbrandsen To: Alexey Melnikov Message-Id: <20130703135622.GI6265@gulbrandsen.priv.no> References: <20130702135454.3325.23598.idtracker@ietfa.amsl.com> <51D41E87.8080307@isode.com> In-Reply-To: <51D41E87.8080307@isode.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Timo Sirainen , imapext@ietf.org Subject: Re: [imapext] I-D Action: draft-ietf-qresync-rfc5162bis-02.txt X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jul 2013 13:56:27 -0000 On Wed, Jul 03, 2013 at 01:52:23PM +0100, Alexey Melnikov wrote: > I was thinking about the section as being a complete replacement of > the definition in RFC 3501. In that case, you ought to completely replace EXPUNGE. Either you extend or replace. Don't mix, please. > I think it is important to point out that there are some conditions > when EXPUNGE responses will still be used. It's so much more pleasant to implement extensions when one can avoid annoying this-or-that-it-depends semantics. Arnt From brong@fastmail.fm Sun Jul 7 04:32:51 2013 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 E2FD221F9E60 for ; Sun, 7 Jul 2013 04:32:51 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ssz3PU-AOX2V for ; Sun, 7 Jul 2013 04:32:47 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) by ietfa.amsl.com (Postfix) with ESMTP id A07E821F9B10 for ; Sun, 7 Jul 2013 04:32:47 -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 48F5920755; Sun, 7 Jul 2013 07:32:46 -0400 (EDT) Received: from betaweb1.nyi.mail.srv.osa ([10.202.2.10]) by compute1.internal (MEProxy); Sun, 07 Jul 2013 07:32:46 -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= VwcidRxyG53xVqHDdDxvQzlfB4k=; b=avA9xMmzWQUqJRRdpSachtg1BNeVsunA TSexJk29ft1Bg5W994vliXT0kBCcYidelS/kLYtvle/81e/QN7PGEb3WjiSaEVBq MJ81pmkfMT1UUhn83xCTD0K0l30R1WKVm8CuZayj5WZwPsa5vDbDTsCryi/Wqena xpXoDNlB8gw= 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=VwcidRxyG53xVqHDdDxvQzlfB4k=; b=Hv7 J2PFlCTccc2ckdnvG5bf4mmJG9VcgrJNRYWb1DfcQpUYf1VtNyvt9/NzVah8E2T8 kGAUKysjUSu/cSB0iN0VugRoZ9Ar/yieK3V7Vnu+u0HSwuK22fNpwnozOv1OHwLs rvu81uBf9JmAatBYAjxvKYKpxoz8R357rS8B9Pjk= Received: by betaweb1.nyi.mail.srv.osa (Postfix, from userid 99) id 04B927402D1; Sun, 7 Jul 2013 07:32:45 -0400 (EDT) Message-Id: <1373196765.24336.140661252768389.65C37C91@webmail.messagingengine.com> X-Sasl-Enc: ZTlxRmKlFrwmvWxreenDQONgFvcJ/PCOpC56AErh+GzJ 1373196765 From: Bron Gondwana To: "Adrien W. de Croy" , Michael M Slusarz , imapext@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain X-Mailer: MessagingEngine.com Webmail Interface - ajax-24b065ff In-Reply-To: References: Date: Sun, 07 Jul 2013 21:32:45 +1000 Subject: Re: [imapext] I-D Action: draft-melnikov-rfc2088bis-00.txt X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Jul 2013 11:32:52 -0000 [catching up on old list emails, have been crazy busy with other things for far too long, sorry] On Wed, Apr 24, 2013, at 08:15 AM, Adrien W. de Croy wrote: > while we're talking about such things, we should revisit the hard-limit > on any IMAP message of 4GB (max unsigned 32 bits). > > I think the time will come quite soon where this limit is unsufficient It's hard coded in Cyrus index files. At least I think I've converted everything internally to size_t, so when we switch to 64 bit indexes, the rest will just work[tm]. > As for LITERAL+ limits, our implementation drops to file over a > threshold, so can go as large as there is free disk space. It would be > more work to figure out a limit to advertise than it's worth for us, so > lack of advertisement should mean no restriction. Cyrus too - it's gmail and similar that slurp the file into memory for processing that need to care (at least for now - one day a 4Gb file will probably not be a concern) Bron. -- Bron Gondwana brong@fastmail.fm From brong@fastmail.fm Sun Jul 7 04:47:11 2013 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 865CA21F9EEC for ; Sun, 7 Jul 2013 04:47:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_55=0.6, RCVD_IN_DNSWL_LOW=-1] 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 nCR9ZZA75e19 for ; Sun, 7 Jul 2013 04:47:07 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) by ietfa.amsl.com (Postfix) with ESMTP id 320B021F9EEB for ; Sun, 7 Jul 2013 04:47:06 -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 16B2B20B8F for ; Sun, 7 Jul 2013 07:47:06 -0400 (EDT) Received: from betaweb1.nyi.mail.srv.osa ([10.202.2.10]) by compute6.internal (MEProxy); Sun, 07 Jul 2013 07:47:06 -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:subject:date:in-reply-to:references; s=mesmtp; bh= r1T3HGCXyQQAFu0zviV/KT5ln2c=; b=jwwtV4YEcFrgFBrG7vcCbNhPtsB/6mz5 aOfMFsrs6uLFijA0w1yiE/pKg5jotAHo+TRY1LbzaLo+6KOJ/VcKaXfsG9BWlgxY 1ejhLO5SmsI+nK8aM2h/4b8y4mNDFcdG5MVHhLztyBYGeCzbkvM/89QalfJkQxf7 +WLtFFleRZU= 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:subject:date:in-reply-to :references; s=smtpout; bh=r1T3HGCXyQQAFu0zviV/KT5ln2c=; b=eloOa liF3GqDS1D7S+nTia+dm6dZHdUvQE8Hgn/i3s7jUOMlCGSA2JLlllSRbEd2CC54F Q0NERYs+ELGoP/xKKIREcjM5SmuVScSnOzBAXRweUlCPOlaxOGXK0jib/erK6elj XiLydQemY9pzRXcgAS6BvIYNYUFE662aGDvPto= Received: by betaweb1.nyi.mail.srv.osa (Postfix, from userid 99) id E23E47402D1; Sun, 7 Jul 2013 07:47:05 -0400 (EDT) Message-Id: <1373197625.27556.140661252769249.6B327861@webmail.messagingengine.com> X-Sasl-Enc: Kv0ZX1AANFy8Kd/SdjjEY5uNXZgg5B1cWW/t28fERg0H 1373197625 From: Bron Gondwana To: imapext@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="_----------=_1373197625275560"; charset="utf-8" X-Mailer: MessagingEngine.com Webmail Interface - ajax-24b065ff Date: Sun, 07 Jul 2013 21:47:05 +1000 In-Reply-To: References: <05c6cf93-2e5e-469d-b356-0751f2bdd5df@flaska.net> Subject: Re: [imapext] GMail's extensions: X-GM-THRID immutability 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, 07 Jul 2013 11:47:11 -0000 This is a multi-part message in MIME format. --_----------=_1373197625275560 Content-Transfer-Encoding: 7bit Content-Type: text/plain On Fri, May 10, 2013, at 07:53 AM, Brandon Long wrote: - Any plans for support of the SORT extensions? We have only the single SORT order in everything we do, so no. Again, we can't load the entire folder into memory just to SORT it on the server, and we're not going to pre-compute and store each possible order. You'll note there is only the one order in all of the Gmail interfaces. Our marketing would say, don't sort, search! I'm actually really surprised at this. In Cyrus we worked on the assumption that a mailbox might have a million messages. We use this data structure for the in-memory index state: struct index_map { modseq_t modseq; modseq_t told_modseq; uint32_t uid; uint32_t recno; uint32_t system_flags; uint32_t user_flags[4]; unsigned int isseen:1; unsigned int isrecent:1; }; Which is 8 + 8 + 4 + 4 + 4 + 32 + (roundup) => 64 bytes per message. So a million messages required 64 megabytes of RAM. The more interesting issue of course is populating the new details fast. Offlineimap does: FETCH 1:* (UID INTERNALDATE FLAGS) So the only question is - do you store INTERNALDATE in an easily fetchable location? Cyrus USED to not store it in the index, so you had to fetch and parse the date header from the cache. That sucked. Now it's in cyrus.index which is 128 bytes per message, so reads in fast, even for "cold" users. Bron. -- Bron Gondwana brong@fastmail.fm --_----------=_1373197625275560 Content-Transfer-Encoding: 7bit Content-Type: text/html
On Fri, May 10, 2013, at 07:53 AM, Brandon Long wrote:
- Any plans for support of the SORT extensions?
 
We have only the single SORT order in everything we do, so no.  Again, we can't load the entire folder into memory just to SORT it on the server, and we're not going to pre-compute and store each possible order.  You'll note there is only the one order in all of the Gmail interfaces.  Our marketing would say, don't sort, search!
 
I'm actually really surprised at this.  In Cyrus we worked on the assumption that a mailbox might have a million messages.  We use this data structure for the in-memory index state:
 
struct index_map {
    modseq_t modseq;
    modseq_t told_modseq;
    uint32_t uid;
    uint32_t recno;
    uint32_t system_flags;
    uint32_t user_flags[4];
    unsigned int isseen:1;
    unsigned int isrecent:1;
};
 
Which is 8 + 8 + 4 + 4 + 4 + 32 + (roundup) => 64 bytes per message.
 
So a million messages required 64 megabytes of RAM.
 
The more interesting issue of course is populating the new details fast.  Offlineimap does:
 
FETCH 1:* (UID INTERNALDATE FLAGS)
 
So the only question is - do you store INTERNALDATE in an easily fetchable location?
 
Cyrus USED to not store it in the index, so you had to fetch and parse the date header from the cache.  That sucked.  Now it's in cyrus.index which is 128 bytes per message, so reads in fast, even for "cold" users.
 
Bron.
 
--
Bron Gondwana
brong@fastmail.fm
 
--_----------=_1373197625275560-- From brong@fastmail.fm Sun Jul 7 04:54:42 2013 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 084D921F994A for ; Sun, 7 Jul 2013 04:54:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.615 X-Spam-Level: X-Spam-Status: No, score=-2.615 tagged_above=-999 required=5 tests=[AWL=-0.683, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_HTML_USL_OBFU=1.666] 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 G7EQw6BkGgwE for ; Sun, 7 Jul 2013 04:54:38 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) by ietfa.amsl.com (Postfix) with ESMTP id 258A021F9815 for ; Sun, 7 Jul 2013 04:54:38 -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 CD55A2094E for ; Sun, 7 Jul 2013 07:54:37 -0400 (EDT) Received: from betaweb1.nyi.mail.srv.osa ([10.202.2.10]) by compute3.internal (MEProxy); Sun, 07 Jul 2013 07:54:37 -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= GmxhuUtbKJLtuhODEvVVpNLYsZ4=; b=UUkoy00LRS2h0ECkCkTxpWafD7d5tf5A xIT3Mk2jXJwXpwvtqYmUnLNJ2vxH/RLlYvO7YnIIw/8gK9WmAbaR5zfm8bb7u3pD a3w98GPjGRuxDDElL88JzFiRYaCphMyciuOaEk9wLWQJ6lH9716f7hm0n3KK/WDu dSemWJnv1I8= 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=GmxhuUtbKJLtuhODEvVVpNLYsZ4=; b=Nag SZg84fFzI+YeSNfEvI2y8nyljaQ32tpJACtzDByXbm0pOiYoEoqZ278NaeIv7jOv YJNmrsBGg53DaU1TGtH9Nnz3zni5uOMVX86S+yNWauBKeHvV1SJBfz5aVaMrezrk hCRAAJGQlItumEmKQEUWpoX6nquXrxmJUVb5Ry+M= Received: by betaweb1.nyi.mail.srv.osa (Postfix, from userid 99) id 94FD87402D1; Sun, 7 Jul 2013 07:54:37 -0400 (EDT) Message-Id: <1373198077.27462.140661252771833.2AFDABA0@webmail.messagingengine.com> X-Sasl-Enc: YJ/E13QbXRTF1muMuTYqw/S4n1DGzF65pg+uZekzYtwo 1373198077 From: Bron Gondwana To: imapext@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="_----------=_1373198077274622"; charset="utf-8" X-Mailer: MessagingEngine.com Webmail Interface - ajax-24b065ff In-Reply-To: References: Date: Sun, 07 Jul 2013 21:54:37 +1000 Subject: Re: [imapext] "NOMODSEQ until needed" optimization 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, 07 Jul 2013 11:54:42 -0000 This is a multi-part message in MIME format. --_----------=_1373198077274622 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="ISO-8859-1" On Fri, May 24, 2013, at 07:40 AM, Dave Cridland wrote: This is a great conversation to be having, but please remember to change the subject line... On 23 May 2013 22:17, "Jan Kundr=E1t" <[1]jkt@flaska.net> wrote: On Thursday, 23 May 2013 21:30:08 CEST, Timo Sirainen wrote: 1. Dovecot doesn't enable modseq tracking until client has requested it in some way by enabling CONDSTORE or QRESYNC. Until then it says at SELECT: * OK [NOMODSEQ] No permanent modsequences This is probably worth explaining in the updated version. I see the benefits of not tracking MODSEQs when not ever requested, but I also understand that clients might want to set a local "don't bother with MODSEQs" bit in their cache if the server returns a NOMODSEQ. I can also see that a client might want to open a mailbox and bypass the usual sycnhronization steps (perhaps it just wants to quickly fetch an item, etc), so the use case for a MODSEQ-supporting client not enabling MODSEQs within some sessions seems valid to me. It's a corner case with potential to cause unpleasant surprises. Originally, I wanted to suggest not returning either of HIGHESTMODSEQ or NOMODSEQ at SELECT time, but this is explicitly forbidden by the RFC. Do you have any numbers on how much performance is gained by not tracking the MODSEQs -- i.e. is your optimization actually worth the complexity? Cheers, Jan -- Trojit=E1, a fast Qt IMAP e-mail client -- [2]http://trojita.flaska.net/ _______________________________________________ imapext mailing list [3]imapext@ietf.org [4]https://www.ietf.org/mailman/listinfo/imapext _______________________________________________ imapext mailing list [5]imapext@ietf.org [6]https://www.ietf.org/mailman/listinfo/imapext I'll reply to this one then :) Cyrus used to not turn on CONDSTORE support for a folder by default - you had to actually set an annotation on the mailbox first. I found that we're always rewriting both the record and the index header every time anyway, so bumping a modseq made sense. Plus we now use it to track changed records for flag changes, and for replication, and ... it just makes sense. It's too useful to be worth trying to optimise out. Bron. -- Bron Gondwana brong@fastmail.fm References 1. mailto:jkt@flaska.net 2. http://trojita.flaska.net/ 3. mailto:imapext@ietf.org 4. https://www.ietf.org/mailman/listinfo/imapext 5. mailto:imapext@ietf.org 6. https://www.ietf.org/mailman/listinfo/imapext --_----------=_1373198077274622 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="ISO-8859-1"
On Fri, May 24, 2013, at 07:40 AM, Dave Cridland wrote:

This is a great conversation to be= having, but please remember to change the subject line...

On 23 May 2013 22:17, "Jan Kundr=E1t" <jkt@flaska.net> wrote:
On Thursday, 23 May 2013 21:30:08 CEST, Timo Sirainen wrote:
 
1. Dovecot doesn't enable modseq tracking until client has requested it in = some way by enabling CONDSTORE or QRESYNC. Until then it says at SELECT:
 
* OK [NOMODSEQ] No permanent modsequences
 
 
This is probably worth explaining in the updated version. I see the benefit= s of not tracking MODSEQs when not ever requested, but I also understand th= at clients might want to set a local "don't bother with MODSEQs" bit in the= ir cache if the server returns a NOMODSEQ. I can also see that a client mig= ht want to open a mailbox and bypass the usual sycnhronization steps (perha= ps it just wants to quickly fetch an item, etc), so the use case for a MODS= EQ-supporting client not enabling MODSEQs within some sessions seems valid = to me. It's a corner case with potential to cause unpleasant surprises.
=
 
Originally, I wanted to suggest not returning either of HIGHESTMODSEQ or NO= MODSEQ at SELECT time, but this is explicitly forbidden by the RFC.
 
Do you have any numbers on how much performance is gained by not tracking t= he MODSEQs -- i.e. is your optimization actually worth the complexity?
<= /div>
 
Cheers,
Jan
 
--
Trojit=E1, a fast Qt IMAP e-mail client -- http://trojita.flaska.net/
_______________________________________________
imapext mailing list
 
_______________________________________________
imapext mailing list
 
I'll reply to this one then :)
 
Cyrus used to not turn on CONDSTORE support for a folder by default - = you had to actually set an annotation on the mailbox first.

I found that we're always rewriting both the record and the index = header every time anyway, so bumping a modseq made sense.  Plus we now= use it to track changed records for flag changes, and for replication, and= ... it just makes sense.  It's too useful to be worth trying to optim= ise out.
 
Bron.
 
--
Bron Gondwana
brong@fastmail.fm
 
--_----------=_1373198077274622-- From brong@fastmail.fm Sun Jul 7 05:07:03 2013 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 6D47621F9EF5 for ; Sun, 7 Jul 2013 05:07:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.221 X-Spam-Level: X-Spam-Status: No, score=-3.221 tagged_above=-999 required=5 tests=[AWL=0.378, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 jm8tttPgifXN for ; Sun, 7 Jul 2013 05:06:59 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) by ietfa.amsl.com (Postfix) with ESMTP id 3418C21F9EF6 for ; Sun, 7 Jul 2013 05:06:58 -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 9845220B5B; Sun, 7 Jul 2013 08:06:58 -0400 (EDT) Received: from betaweb1.nyi.mail.srv.osa ([10.202.2.10]) by compute1.internal (MEProxy); Sun, 07 Jul 2013 08:06:58 -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= l4hD58PQcJ/jfMNrdz/e+r/qxhI=; b=b+ey+2iU3Uebp7RqeSio48eQel8HwAZ2 0aXTAuQjMYZiJ3/XQAlb498ugUmauP6GZxY6DF3O3hr7YxcmlnXnpRvCL55YfU6y m//1uiNu1j2jwZA8lbJHVs6Q8kCb/FiiHrQzZu+i0zbOGC1XHFTwFtRdmrL1GbyD wqx8Tps68XM= 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=l4hD58PQcJ/jfMNrdz/e+r/qxhI=; b=HcOln PkoILKaYFReTiG89TC+EmE/S+ek7OuiEwNMjpB9TCiC1eTzZQXg7bTSlK/50oDRz nAeA+TB5sWjySdbXEu6pqRws2XEjlt3nArpVK1asCYQT0kEyJ6de/D3R6kezC1Lo xod7ZrI9XlWmLXtUqbuIXOzRIxw+lEp8Tekzi4= Received: by betaweb1.nyi.mail.srv.osa (Postfix, from userid 99) id 602EF7402D1; Sun, 7 Jul 2013 08:06:58 -0400 (EDT) Message-Id: <1373198818.28914.140661252774997.7D3F5F4E@webmail.messagingengine.com> X-Sasl-Enc: ba9HzRQP3WXRyuV8rxGd1f1yNWtTTcFnXzftwwHV/Vvw 1373198818 From: Bron Gondwana To: Timo Sirainen , "Adrien W. de Croy" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain X-Mailer: MessagingEngine.com Webmail Interface - ajax-24b065ff Date: Sun, 07 Jul 2013 22:06:58 +1000 In-Reply-To: References: Cc: Alexey Melnikov , Eliot Lear , imapext@ietf.org, Dave Cridland Subject: Re: [imapext] WG participants please READ Re: qresync WG adoption call 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, 07 Jul 2013 12:07:03 -0000 On Sun, May 26, 2013, at 10:33 AM, Timo Sirainen wrote: > On 26.5.2013, at 1.55, Adrien W. de Croy wrote: > > In general, compared to messages, folders in IMAP are IMO second class citizens. No way to advertise folder deletion, renaming etc. > > > > What could be interesting would be a virtual/meta-folder called "FOLDERS", which treats every folder as a record in this virtual folder. Then you could just do a modseq on this. That's what I'll be doing in Cyrus soon. I'll be doing a modseq for everything about each user, including their sieve scripts, folders, private metadata, etc. This is to allow fast replication more than anything else. We also have a single "HIGHESTMODSEQ" across all a user's folders now to allow fast client sync. > I've solved this internally in Dovecot by giving a GUID for each mailbox, which allows tracking renames and deletions. Mails also have GUIDs. I wonder if clients would be interested in having a standard GUID extension for these.. Ditto in Cyrus. > > Again, out of scope for this. > > Yeah. But let's not forget it! Bron. -- Bron Gondwana brong@fastmail.fm From brong@fastmail.fm Sun Jul 7 05:20:07 2013 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 63D7B21F9CEF for ; Sun, 7 Jul 2013 05:20:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.316 X-Spam-Level: X-Spam-Status: No, score=-3.316 tagged_above=-999 required=5 tests=[AWL=0.284, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 PJndsY19DTab for ; Sun, 7 Jul 2013 05:20:03 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) by ietfa.amsl.com (Postfix) with ESMTP id D384521F9BC2 for ; Sun, 7 Jul 2013 05:20:02 -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 63960209DF for ; Sun, 7 Jul 2013 08:20:01 -0400 (EDT) Received: from betaweb1.nyi.mail.srv.osa ([10.202.2.10]) by compute1.internal (MEProxy); Sun, 07 Jul 2013 08:20:01 -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:subject:date:in-reply-to:references; s=mesmtp; bh= NT/zlZJ6r5lKciaB1OCL4ME9Glw=; b=pehEbKEbswptvtYtB8kEzUzFY8l8jIL8 fe4bm8FtVg815OyH6WzgjX5qMlGOIOU+SEMj5jr7sF4bNZNpIfdT6wqTeJ7QAwrS TWNPnCoZ2LL3PIJi6yt0cuoNTbIMLgv7Whq6HH17Mf+N3dO3LqRqM+hel3+iJgKW a6i59KwL2f8= 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:subject:date:in-reply-to :references; s=smtpout; bh=NT/zlZJ6r5lKciaB1OCL4ME9Glw=; b=Nnu4b GOaTOgQrbim5m6MN7CO2EGAwz0KHa2q/NQ/fbgbo2WHT6RyoFSi6CmwELefQPvqx zDkp6Zr0zjyabRFY4BNn4UUEuHb7crl6rgKw3ZwPDzYLv4wvSlv0IIwbpSmiR73L BoLdbBru4JEJJhvw1AbRHDtzc7G/+PFlvgbqQs= Received: by betaweb1.nyi.mail.srv.osa (Postfix, from userid 99) id 2D44B7402D1; Sun, 7 Jul 2013 08:20:01 -0400 (EDT) Message-Id: <1373199601.31449.140661252776553.3ADE59A2@webmail.messagingengine.com> X-Sasl-Enc: /6at13S6QMVQamSoHdZJYrs5oiifZb/UXAK+h3qTSx4Y 1373199601 From: Bron Gondwana To: imapext@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain X-Mailer: MessagingEngine.com Webmail Interface - ajax-24b065ff Date: Sun, 07 Jul 2013 22:20:01 +1000 In-Reply-To: <51B21224.8060808@andrew.cmu.edu> References: <14830_1370624399_r57GxvRc017415_6291FAD2FBE3593797DEC90C@dyn-72-33-212-232.uwnet.wisc.edu> <51B21224.8060808@andrew.cmu.edu> Subject: Re: [imapext] LOGINDISABLED 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, 07 Jul 2013 12:20:07 -0000 [sorry again for late replies] On Sat, Jun 8, 2013, at 03:02 AM, Ken Murchison wrote: > On 06/07/2013 12:59 PM, Cyrus Daboo wrote: > > Hi, > > RFC3501 defines a LOGINDISABLED property that is used prior to > > STARTTLS (or some out of band security) being in place to ensure the > > LOGIN command is not used in an insecure environment. Some servers > > also offer configuration to also disable plain text authentication > > even when a security layer is in place. In that situation, should > > (must) the server advertise LOGINDISABLED in capabilities sent after > > STARTTLS? The spec really does not cover that case explicitly. > > > > Personally I think anytime the server is going to reject LOGIN it > > ought to advertise LOGINDISABLED to ensure clients don't "blindly" > > send the clear text credentials - because the purpose of disabling > > LOGIN is to stop that happening in the first place > > +1 We found that the average half-arsed client sent the credentials without even looking at the capabilities. Plus any half-dedicated man in the middle is going to strip LOGINDISABLED from the capabilities response anyway. So, nice idea - but it's not a security method. Which is why we only allow SSL on port 993 now. Bron. -- Bron Gondwana brong@fastmail.fm From brong@fastmail.fm Sun Jul 7 05:29:56 2013 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 1333121F9E7E for ; Sun, 7 Jul 2013 05:29:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.372 X-Spam-Level: X-Spam-Status: No, score=-3.372 tagged_above=-999 required=5 tests=[AWL=0.226, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 fE2mjpl3zTpI for ; Sun, 7 Jul 2013 05:29: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 B4CE521F9EDD for ; Sun, 7 Jul 2013 05:29:51 -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 675142086D; Sun, 7 Jul 2013 08:29:51 -0400 (EDT) Received: from betaweb1.nyi.mail.srv.osa ([10.202.2.10]) by compute2.internal (MEProxy); Sun, 07 Jul 2013 08:29:51 -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= IIgw1Xv0+Itl4lXqhfPqkfzAJ3k=; b=KJG2A4tkigKoYPVb1aVtJpIb8JhCFY9a dm56VTGEIRk3DEEYtIPPtB+UD/FeyIxgE59nr+wNvlYLrzPT7uhiCQc2YnVDTrWB OX25pZLjUA9rnlBg+ikK64ov7aoI9IUkx+/HFRXCLfq0yc+dQ/xVY4AOgjVyHlAg 15KWeOuGnM4= 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=IIgw1Xv0+Itl4lXqhfPqkfzAJ3k=; b=Cs0 wWwb2L4N98OZ7+fSXogCT5qKzkp/GDRjtj7kEMIrIB8MWevqs+T59fKgktqsQRxf +l4pEW0hPLCrhmJX2uvbQTjv1OxQ913DO7rkTP5SzZlswQZLWmlBFVNu38d5C4pa NT90WydNc9ZrRhj+89NVEpwBgMSdmOsrmVYaXUbQ= Received: by betaweb1.nyi.mail.srv.osa (Postfix, from userid 99) id 2BD8F7402D1; Sun, 7 Jul 2013 08:29:51 -0400 (EDT) Message-Id: <1373200191.32371.140661252777825.1370EB99@webmail.messagingengine.com> X-Sasl-Enc: H1LkvB3fM6FhoQGKKceIPAFn1T5QXDlDNpwdC3132TsH 1373200191 From: Bron Gondwana To: Alexey Melnikov , Dave Cridland MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="_----------=_1373200191323711"; charset="utf-8" X-Mailer: MessagingEngine.com Webmail Interface - ajax-24b065ff In-Reply-To: <51B776D5.5010703@isode.com> References: <51B62D75.8040001@andrew.cmu.edu> <83FFBF44-0FF9-4195-AA45-5BE6179A48E0@iki.fi> <51B776D5.5010703@isode.com> Date: Sun, 07 Jul 2013 22:29:51 +1000 Cc: Timo Sirainen , imapext@ietf.org Subject: Re: [imapext] CONDSTORE / QRESYNC X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Jul 2013 12:29:56 -0000 This is a multi-part message in MIME format. --_----------=_1373200191323711 Content-Transfer-Encoding: 7bit Content-Type: text/plain On Wed, Jun 12, 2013, at 05:13 AM, Alexey Melnikov wrote: On 11/06/2013 14:49, Dave Cridland wrote: On Tue, Jun 11, 2013 at 1:38 PM, Timo Sirainen <[1]tss@iki.fi> wrote: On 11.6.2013, at 13.39, Dave Cridland <[2]dave@cridland.net> wrote: > On the other hand, I cannot think of a case when I'd actually want per-metadata MODSEQ - it's also not clear to me that any extant servers actually support this anyway. In the absence of per-metadata MODSEQ, then a client can add a flag if the message is still unseen (for example), which seems to me to be a more useful case. > > Does any server actually implement per-metadata MODSEQ? Does anyone want this? Perhaps it could be a useful difference for message flag changes vs. annotation changes. But I haven't implemented annotation support yet, so I'm not really sure. One possible option there would be to call this out as out of scope, and require the annotation extension to have its own modification sequence. If this is a question of what to say in CONDSTORE, I would be Ok with that. For example saying something like "CONDSTORE requires one modseq per all flags/keywords. Other IMAP extensions might add additional modseqs for other metadata (or might reuse the flag one)." would be Ok. I would be less happy with modifying existing syntax (apart from removing something which is already optional) or requiring other extensions to use their own per-metadata modseqs. I agree with this. At the moment we don't store separate modseqs with the annotations/metadata. I've been considering it. It would be nice not to pay the full metadata cost (at the moment it's a 200ish byte preview) during replication for every flag change. Bron. -- Bron Gondwana brong@fastmail.fm References 1. mailto:tss@iki.fi 2. mailto:dave@cridland.net --_----------=_1373200191323711 Content-Transfer-Encoding: 7bit Content-Type: text/html
On Wed, Jun 12, 2013, at 05:13 AM, Alexey Melnikov wrote:
On 11/06/2013 14:49, Dave Cridland wrote:
On Tue, Jun 11, 2013 at 1:38 PM, Timo Sirainen <tss@iki.fi> wrote:
 
On 11.6.2013, at 13.39, Dave Cridland <dave@cridland.net> wrote:
 
> On the other hand, I cannot think of a case when I'd actually want per-metadata MODSEQ - it's also not clear to me that any extant servers actually support this anyway. In the absence of per-metadata MODSEQ, then a client can add a flag if the message is still unseen (for example), which seems to me to be a more useful case.
>
> Does any server actually implement per-metadata MODSEQ? Does anyone want this?
 
Perhaps it could be a useful difference for message flag changes vs. annotation changes. But I haven't implemented annotation support yet, so I'm not really sure.
 
 
 
 
One possible option there would be to call this out as out of scope, and require the annotation extension to have its own modification sequence.
If this is a question of what to say in CONDSTORE, I would be Ok with that. For example saying something like "CONDSTORE requires one modseq per all flags/keywords. Other IMAP extensions might add additional modseqs for other metadata (or might reuse the flag one)." would be Ok. I would be less happy with modifying existing syntax (apart from removing something which is already optional) or requiring other extensions to use their own per-metadata modseqs.
 
I agree with this.  At the moment we don't store separate modseqs with the annotations/metadata.  I've been considering it.  It would be nice not to pay the full metadata cost (at the moment it's a 200ish byte preview) during replication for every flag change.
 
Bron.
 
--
Bron Gondwana
brong@fastmail.fm
 
--_----------=_1373200191323711-- From dave@cridland.net Sun Jul 7 08:34:59 2013 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 E2C0B21F9930 for ; Sun, 7 Jul 2013 08:34:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.976 X-Spam-Level: X-Spam-Status: No, score=-1.976 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] 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 zpS23Rk6YK0e for ; Sun, 7 Jul 2013 08:34:59 -0700 (PDT) Received: from mail-gg0-x234.google.com (mail-gg0-x234.google.com [IPv6:2607:f8b0:4002:c02::234]) by ietfa.amsl.com (Postfix) with ESMTP id EB5AE21F8FF3 for ; Sun, 7 Jul 2013 08:34:58 -0700 (PDT) Received: by mail-gg0-f180.google.com with SMTP id i6so1355092ggm.39 for ; Sun, 07 Jul 2013 08:34:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cridland.net; s=google; h=content-type:mime-version:in-reply-to:references:subject:x-mailer :date:message-id:from:to:cc; bh=G7LSatcNE94ebPAa6NEUcLSNxXksWalq+hjgtDKix1o=; b=Lbm8qROgczZ9I7sw3Hgp5xb03tNmpB98MSC2lEbf6AawQjCJvnSJOdHRypMlHlg/3X TE/1v2u5CxqmeAaxSMy/P9xJB7J4sUbx4IVwx70wfzj3FxdG0ldR0bAIoJ8kgyvWmEz5 weuAgTYSKiOjf9rwiukxDypcQWwLHDJAYbsMc= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=content-type:mime-version:in-reply-to:references:subject:x-mailer :date:message-id:from:to:cc:x-gm-message-state; bh=G7LSatcNE94ebPAa6NEUcLSNxXksWalq+hjgtDKix1o=; b=ogn4zMLxt+Oi3/ge+JiQjnYy+BmGwS2ta2PB+4tUzBnc3QF9u6BrPSMFYWo2F8u2yw yU/mUvctu7dWgS1DzGLW52gTzwxJIVz7CMCTEasuFuPFhiDE407LGKuPpdQgZr3vSlyN TD66PNtH8a0F7B2XWDQM4BdoMqSXAfrj2OUtGvXdHjsYZR7ImHyKFymcsVyjgxYbkgPi IQuxtSWwr1CsVxHBuSQ4z7kUI2ZQPa7zkMNVL3f0bXD7cAG+5jxoBZaDyRK64Qa2eOPs ZNDrVBkI3KxRJwVwIgsvV6Yl9AsMgt/F+9WCWibxHNABiFP/eZSnTSqBPmVkuaibRUqI EEbA== X-Received: by 10.236.15.194 with SMTP id f42mr10128191yhf.104.1373211298410; Sun, 07 Jul 2013 08:34:58 -0700 (PDT) Received: from [192.168.56.1] (173-10-181-165-BusName-washingtonDC.hfc.comcastbusiness.net. [173.10.181.165]) by mx.google.com with ESMTPSA id s65sm29502119yhs.14.2013.07.07.08.34.57 for (version=TLSv1.1 cipher=RC4-SHA bits=128/128); Sun, 07 Jul 2013 08:34:57 -0700 (PDT) Content-Type: multipart/alternative; boundary="===============1493588734==" MIME-Version: 1.0 In-Reply-To: <1373200191.32371.140661252777825.1370EB99@webmail.messagingengine.com> References: <83FFBF44-0FF9-4195-AA45-5BE6179A48E0@iki.fi> <51B62D75.8040001@andrew.cmu.edu> <1373200191.32371.140661252777825.1370EB99@webmail.messagingengine.com> <51B776D5.5010703@isode.com> X-Mailer: Inky (TM) v1.0.51D7.5905 ("Epoch") Date: Sun, 07 Jul 2013 15:34:57 -0000 Message-Id: From: Dave Cridland To: Bron Gondwana X-Gm-Message-State: ALoCoQkVuAE9RMlN1rse2mpKoFtN2rpK/DWbsXVVXErwCBf8YHx7BIHgoyM4CPKAN1JrysRsIIiP Cc: Alexey Melnikov , Timo Sirainen , imapext@ietf.org Subject: Re: [imapext] CONDSTORE / QRESYNC X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Jul 2013 15:35:00 -0000 --===============1493588734== Content-Type: text/plain; charset="iso-8859-1" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Bron Gondwana wrote: On Wed, Jun 12, 2013, at 05:13 AM, Alexey Melnikov wrote: If this is a question of what to say in CONDSTORE, I would be Ok with that. For example saying something like "CONDSTORE requires one modseq per all flags/keywords. Other IMAP extensions might add additional modseqs for other metadata (or might reuse the flag one)." would be Ok. I would be less happy with modifying existing syntax (apart from removing something which is already optional) or requiring other extensions to use their own per- metadata modseqs. I agree with this. At the moment we don't store separate modseqs with the annotations/metadata. I've been considering it. It would be nice not to pay the full metadata cost (at the moment it's a 200ish byte preview) during replication for every flag change. Do you have any specific text you'd like to see here? --===============1493588734== Content-Type: text/html; charset="iso-8859-1" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable
Bron Gondwana wrote:
=A0
On Wed, Jun 12, 2013, at 05:13 AM, Alexey Melnikov wrote:
If this is a question of what to say in CONDSTORE, I would be O= k with that. For example saying something like "CONDSTORE requires one mods= eq per all flags/keywords. Other IMAP extensions might add additional modse= qs for other metadata (or might reuse the flag one)." would be Ok. I would = be less happy with modifying existing syntax (apart from removing something= which is already optional) or requiring other extensions to use their own = per-metadata modseqs.
=A0
I agree with this.=A0 At the moment we don't store separate modseqs = with the annotations/metadata.=A0 I've been considering it.=A0 It would be = nice not to pay the full metadata cost (at the moment it's a 200ish byte pr= eview) during replication for every flag change.
=A0
Do you have any specific text you'd like to see here?
--===============1493588734==-- From brong@fastmail.fm Mon Jul 8 05:42:38 2013 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 4A07711E81D9 for ; Mon, 8 Jul 2013 05:42:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.409 X-Spam-Level: X-Spam-Status: No, score=-3.409 tagged_above=-999 required=5 tests=[AWL=0.189, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 QyJ7mpi7CF71 for ; Mon, 8 Jul 2013 05:42:34 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) by ietfa.amsl.com (Postfix) with ESMTP id C592111E81CB for ; Mon, 8 Jul 2013 05:42:33 -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 7CF5720ECD for ; Mon, 8 Jul 2013 08:42:30 -0400 (EDT) Received: from web1.nyi.mail.srv.osa ([10.202.2.211]) by compute2.internal (MEProxy); Mon, 08 Jul 2013 08:42:30 -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= mNpMthAcO3QY3GgD0dMh1nbt9Cw=; b=G7KmgyctfquhAMU6UT1Avvedl2uUZA3z tQoRwdHY1V4d+yWq1mI4Dtawd4y1yyB7a5EQoXyRGEVM0Ka4m0i5KyOzstL1vf1D dXn7HJD3jytmAw3aiHkReKzJHNubHSxblkz+WXohwvKAhh8qDJJT7+J7qEM9mwuf iqAoqqla+Kk= 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=mNpMthAcO3QY3GgD0dMh1nbt9Cw=; b=QLB oPtzXOxO+ak+cLncHixAs+J1zJ9bL08TYWUHhkFlJuyMBq2gijiSvLq8wLWOWtU1 cT9Ib2tPOiI0o3LUmzfvNR693ufgVFtH/Wnh2sZnjfTu29vdu3L4kDkIabiY+x3U NjY8AIvtQGt0xNgDb8cv7zjIrDlWpuCgJXzlORcI= Received: by web1.nyi.mail.srv.osa (Postfix, from userid 99) id F0008F00003; Mon, 8 Jul 2013 08:42:29 -0400 (EDT) Message-Id: <1373287349.12455.140661253112782.11557D3D@webmail.messagingengine.com> X-Sasl-Enc: mJgrxYXU68egqi7NuGY6z/3e5tb3IifWqgQAzoGR1+Y8 1373287349 From: Bron Gondwana To: imapext@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="_----------=_1373287349124551"; charset="utf-8" X-Mailer: MessagingEngine.com Webmail Interface - ajax-cea5092a In-Reply-To: References: <83FFBF44-0FF9-4195-AA45-5BE6179A48E0@iki.fi> <51B62D75.8040001@andrew.cmu.edu> <1373200191.32371.140661252777825.1370EB99@webmail.messagingengine.com> <51B776D5.5010703@isode.com> Date: Mon, 08 Jul 2013 22:42:29 +1000 Subject: Re: [imapext] CONDSTORE / QRESYNC X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jul 2013 12:42:38 -0000 This is a multi-part message in MIME format. --_----------=_1373287349124551 Content-Transfer-Encoding: 7bit Content-Type: text/plain On Mon, Jul 8, 2013, at 01:34 AM, Dave Cridland wrote: Bron Gondwana wrote: On Wed, Jun 12, 2013, at 05:13 AM, Alexey Melnikov wrote: If this is a question of what to say in CONDSTORE, I would be Ok with that. For example saying something like "CONDSTORE requires one modseq per all flags/keywords. Other IMAP extensions might add additional modseqs for other metadata (or might reuse the flag one)." would be Ok. I would be less happy with modifying existing syntax (apart from removing something which is already optional) or requiring other extensions to use their own per-metadata modseqs. I agree with this. At the moment we don't store separate modseqs with the annotations/metadata. I've been considering it. It would be nice not to pay the full metadata cost (at the moment it's a 200ish byte preview) during replication for every flag change. Do you have any specific text you'd like to see here? Thinking about it... There's another thing I'm trying to get into coherent words now. There are two very different things that happen with qresync selects: 1) the server has full information, and sends a tiny bit of data. 2) the server doesn't have full information, and dumps a potentially large amount of information. A client may want case 1, but not want case 2. A server might want to generate case 1, but not all the data for case 2. So it makes sense to distingish between the two cases. A way to say "tell me what's changed if you know, or just tell me there's not enough information and I'll query for the data I need". Anyway... that's what's going through my head today. We do something similar in the Cyrus sync protocol, where if the DELETEDMODSEQ (highmark of forgotten data) is less than last time, we can just do a delta sync, otherwise we have to do a full metadata sync. Bron. -- Bron Gondwana brong@fastmail.fm --_----------=_1373287349124551 Content-Transfer-Encoding: 7bit Content-Type: text/html
On Mon, Jul 8, 2013, at 01:34 AM, Dave Cridland wrote:
Bron Gondwana wrote:
 
On Wed, Jun 12, 2013, at 05:13 AM, Alexey Melnikov wrote:
If this is a question of what to say in CONDSTORE, I would be Ok with that. For example saying something like "CONDSTORE requires one modseq per all flags/keywords. Other IMAP extensions might add additional modseqs for other metadata (or might reuse the flag one)." would be Ok. I would be less happy with modifying existing syntax (apart from removing something which is already optional) or requiring other extensions to use their own per-metadata modseqs.
 
I agree with this.  At the moment we don't store separate modseqs with the annotations/metadata.  I've been considering it.  It would be nice not to pay the full metadata cost (at the moment it's a 200ish byte preview) during replication for every flag change.
 
Do you have any specific text you'd like to see here?
 
Thinking about it...
 
There's another thing I'm trying to get into coherent words now.  There are two very different things that happen with qresync selects:
 
1) the server has full information, and sends a tiny bit of data.
2) the server doesn't have full information, and dumps a potentially large amount of information.
 
A client may want case 1, but not want case 2.  A server might want to generate case 1, but not all the data for case 2.
 
So it makes sense to distingish between the two cases.  A way to say "tell me what's changed if you know, or just tell me there's not enough information and I'll query for the data I need".
 
Anyway... that's what's going through my head today.  We do something similar in the Cyrus sync protocol, where if the DELETEDMODSEQ (highmark of forgotten data) is less than last time, we can just do a delta sync, otherwise we have to do a full metadata sync.
 
Bron.
 
--
Bron Gondwana
brong@fastmail.fm
 
--_----------=_1373287349124551-- From dave@cridland.net Mon Jul 8 06:41:02 2013 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 7BD6121F9AAC for ; Mon, 8 Jul 2013 06:41:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.976 X-Spam-Level: X-Spam-Status: No, score=-1.976 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] 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 nRpfedDKZdGF for ; Mon, 8 Jul 2013 06:41:01 -0700 (PDT) Received: from mail-qc0-x236.google.com (mail-qc0-x236.google.com [IPv6:2607:f8b0:400d:c01::236]) by ietfa.amsl.com (Postfix) with ESMTP id 8F46F21F8F4F for ; Mon, 8 Jul 2013 06:41:01 -0700 (PDT) Received: by mail-qc0-f182.google.com with SMTP id e10so2295736qcy.27 for ; Mon, 08 Jul 2013 06:40:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cridland.net; s=google; h=content-type:mime-version:in-reply-to:references:subject:x-mailer :date:message-id:from:to:cc; bh=ITFQVZ5CCicugI9imfEcCoEkOFyPnNE9CGcJJ+ClEUU=; b=VqhhHvz/fvBa6Cpk5SHgp/GNWCaOH0phmnA3hjmR3UWX2pFOnkwTxUOtI6kkNxq8zn fiolDqaKKKYkiZcl/9cqlxam+8DK9U4hbVWtXaDvrNN55YcwntNhHaLURCJLVw65fzmy eW3SmUA6MyzQwUtTlE/ji6tw5+uie59ruR+wg= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=content-type:mime-version:in-reply-to:references:subject:x-mailer :date:message-id:from:to:cc:x-gm-message-state; bh=ITFQVZ5CCicugI9imfEcCoEkOFyPnNE9CGcJJ+ClEUU=; b=FRWXRBl5mFHFZU315E8F8RrY7Z0/Xk4FDYASuFQDeHePFu0KRDnAFDQhpyW6JCCoLO AzE6w1e5fOBm3w7QkQwx+wSl8IU8S7/zp0nzMFQWbm67LOPWenDhxFEvJiX84ri+t10a dE0xVzR6FRx6P873U1SaPCdJHUX8rwMBJ9O+fYtaDqnAJwnq2kVNYWN79YaQExCwkNZk hc1oYqv7YIMbFbfBqOFx7mGzLTz8iRYRAlxys4PqctvpNLJsZ6N1sW+zS91o0zp6J37m LWsHNQLTCEH+OEtdpFdp2+gTInor+kTU6EUDA8H5IoTU/eQxJnMSyQS6mKjNofVKpaxu OcDw== X-Received: by 10.49.12.114 with SMTP id x18mr12167307qeb.25.1373290859771; Mon, 08 Jul 2013 06:40:59 -0700 (PDT) Received: from [192.168.56.1] (173-10-181-165-BusName-washingtonDC.hfc.comcastbusiness.net. [173.10.181.165]) by mx.google.com with ESMTPSA id 11sm13125996qek.1.2013.07.08.06.40.58 for (version=TLSv1.1 cipher=RC4-SHA bits=128/128); Mon, 08 Jul 2013 06:40:58 -0700 (PDT) Content-Type: multipart/alternative; boundary="===============1342807974==" MIME-Version: 1.0 In-Reply-To: <1373287349.12455.140661253112782.11557D3D@webmail.messagingengine.com> References: <51B62D75.8040001@andrew.cmu.edu> <83FFBF44-0FF9-4195-AA45-5BE6179A48E0@iki.fi> <1373200191.32371.140661252777825.1370EB99@webmail.messagingengine.com> <51B776D5.5010703@isode.com> <1373287349.12455.140661253112782.11557D3D@webmail.messagingengine.com> X-Mailer: Inky (TM) v1.0.51D7.5905 ("Epoch") Date: Mon, 08 Jul 2013 13:40:58 -0000 Message-Id: From: Dave Cridland To: Bron Gondwana X-Gm-Message-State: ALoCoQlJxX7vLnHr8wp0wqz+VjQuYuM7ASyTpAOSpyOWwvw+IaIQGfGgLw/FPYg4Ws0ao3xCt91S Cc: imapext@ietf.org Subject: Re: [imapext] CONDSTORE / QRESYNC X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jul 2013 13:41:02 -0000 --===============1342807974== Content-Type: text/plain; charset="iso-8859-1" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Bron Gondwana wrote: 1) the server has full information, and sends a tiny bit of data. 2) the server doesn't have full information, and dumps a potentially large amount of information. A client may want case 1, but not want case 2. A server might want to generate case 1, but not all the data for case 2. In theory, that can't happen. In principle, the protocol's designed such that a server has all the information to minimize the transfer. There's two discrete information dumps that happen: a) FLAGS (and in principle other metadata) changed since the given MODSEQ. This grows proportionally to the amount of changes, but it will never transfer more data than is needed. Note that a client can reduce the scope here by claiming only a particular range is important - Polymer did this, as I recall, by requesting only "old" messages. b) VANISHED messages since the MODSEQ given. If a server doesn't store the deleted MODSEQs, then this could grow, but a client has the ability to control this by sending the mapping data samples which can limit it. In addition, this compresses well, of course, in the set representation. So a really poor client might cause a lot of work for a server, but I don't think that's particularly limited to QRESYNC - a client not using QRESYNC at all and doing the classic "UID FETCH 1:* (FLAGS)" will never cause more work than a bad QRESYNC client, will it? (Outside of pathological cases like a client asking for everything, with a MODSEQ of 1 - even then it's not significantly more data). Dave. --===============1342807974== Content-Type: text/html; charset="iso-8859-1" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable
Bron Gondwana wrote:
1) the server has full information, and sends a tiny bit of data.
2) the server doesn't have full information, and dumps a potentially= large amount of information.
=A0
A client may want case 1, but not want case 2.=A0 A server might wan= t to generate case 1, but not all the data for case 2.
=A0
=A0
In theory, that can't happen. In principle, the protocol's designed such t= hat a server has all the information to minimize the transfer.
=A0
There's two discrete information dumps that happen:
=A0
a) FLAGS (and in principle other metadata) changed since the given MODSEQ.= This grows proportionally to the amount of changes, but it will never tran= sfer more data than is needed. Note that a client can reduce the scope here= by claiming only a particular range is important - Polymer did this, as I = recall, by requesting only "old" messages.
=A0
b) VANISHED messages since the MODSEQ given. If a server doesn't store the= deleted MODSEQs, then this could grow, but a client has the ability to con= trol this by sending the mapping data samples which can limit it. In additi= on, this compresses well, of course, in the set representation.
=A0
So a really poor client might cause a lot of work for a server, but I don'= t think that's particularly limited to QRESYNC - a client not using QRESYNC= at all and doing the classic "UID FETCH 1:* (FLAGS)" will never cause more= work than a bad QRESYNC client, will it? (Outside of pathological cases li= ke a client asking for everything, with a MODSEQ of 1 - even then it's not = significantly more data).
=A0
Dave.
--===============1342807974==-- From blong@google.com Mon Jul 8 13:20:35 2013 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 8DB5421F9546 for ; Mon, 8 Jul 2013 13:20:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.377 X-Spam-Level: X-Spam-Status: No, score=-1.377 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_55=0.6, NO_RELAYS=-0.001] 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 5fjYySCVeuwb for ; Mon, 8 Jul 2013 13:20:34 -0700 (PDT) Received: from mail-qc0-x22a.google.com (mail-qc0-x22a.google.com [IPv6:2607:f8b0:400d:c01::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 3C29E21F8B04 for ; Mon, 8 Jul 2013 13:20:34 -0700 (PDT) Received: by mail-qc0-f170.google.com with SMTP id s1so2589051qcw.1 for ; Mon, 08 Jul 2013 13:20:31 -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; bh=D3fwcn3uXs39r6vZf8bgnOvDHdnLUxsMqCnoy0Aav78=; b=DdbEJZwqoUqBFXvf2God85fyjKzR7Y5nwDL3lSrX2y9aPlOgJ6sf+dFrmu9V7qxt4P z2PJQwn+lccfQt39dbuEHVUtnT7fEsiv8PAO3VyYwWPLHiD37bHTJCNzcfLQZFeZ5fk8 +uBjDzzdKxdVBdyvDHf28tqU0GlfiR7kNRiRE2a3W+3CHMix7d6EOxBzqJ90Op4o6RFE KpF6L/HeKhlqVQTIDf+487Aa1VDECehVCbcs2LyjVPP+o0EpPYc6j4jURwAIsfCiArZ4 1NtIsURYIlPkvOlwlnBFMIZ5nRSumCQtLZzvI57DkutcED2uY0qwT51e2B4T/z3ZgLmv UVtw== 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-gm-message-state; bh=D3fwcn3uXs39r6vZf8bgnOvDHdnLUxsMqCnoy0Aav78=; b=e/hM0o7LalZ6//wPNW/KH01/5Lsk1GtIBNZIhsfDj/2taWegatP9mCJRBuJAhEXu39 n7uuk53D4upM5V49RA7Ej+VSPyaTd08m2Zhgve/Nyxl/K6+s+4A1zNjXkozbdwEwLMzO MHGvuZCUgXWfR+qXdyCpib3w9HHtV9YjABcTo7LoP2Dz7dAbYv3blbE0M+vrwBLBK2WN lzqxgq17hjjjvhT5cd3uX1mm3/JqJfRE8LJkGln/AU2AstwaT99DwCT7e3kHCQ1tnCDE VsAksxbKQukOFM8x15rjHL9Q1GCFebNilpum1eLe3CrtSRiHqhmql7DwWMHrH1owkFp1 uJ0w== MIME-Version: 1.0 X-Received: by 10.229.16.132 with SMTP id o4mr4059566qca.99.1373314830952; Mon, 08 Jul 2013 13:20:30 -0700 (PDT) Received: by 10.229.114.137 with HTTP; Mon, 8 Jul 2013 13:20:30 -0700 (PDT) In-Reply-To: <1373197625.27556.140661252769249.6B327861@webmail.messagingengine.com> References: <05c6cf93-2e5e-469d-b356-0751f2bdd5df@flaska.net> <1373197625.27556.140661252769249.6B327861@webmail.messagingengine.com> Date: Mon, 8 Jul 2013 13:20:30 -0700 Message-ID: From: Brandon Long To: Bron Gondwana Content-Type: multipart/alternative; boundary=0015175d00daaa2ef004e105c6fe X-Gm-Message-State: ALoCoQkyYhmpIh8OiA1VrAswDH+UUuT0NszdCgXWvNpYhFm4trTu3I2yUGkV0Udc/PtshyL2ZD8qI4KS6+hdLkubGdDPtSuuPZV5uRZpccDkj9NxgX4YRYIfzrnPBxm55Y6SzzHH8Syj8aimbdaSzBIEr/aZE9rKgYrTWnoHvo0KoqqJPz2jQhcbAkpDmATwN1V70C1+em+j Cc: "imapext@ietf.org" Subject: Re: [imapext] GMail's extensions: X-GM-THRID immutability 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, 08 Jul 2013 20:20:35 -0000 --0015175d00daaa2ef004e105c6fe Content-Type: text/plain; charset=ISO-8859-1 On Sun, Jul 7, 2013 at 4:47 AM, Bron Gondwana wrote: > ** > On Fri, May 10, 2013, at 07:53 AM, Brandon Long wrote: > > - Any plans for support of the SORT extensions? > > > We have only the single SORT order in everything we do, so no. Again, we > can't load the entire folder into memory just to SORT it on the server, and > we're not going to pre-compute and store each possible order. You'll note > there is only the one order in all of the Gmail interfaces. Our marketing > would say, don't sort, search! > > > I'm actually really surprised at this. In Cyrus we worked on the > assumption that a mailbox might have a million messages. We use this data > structure for the in-memory index state: > > struct index_map { > modseq_t modseq; > modseq_t told_modseq; > uint32_t uid; > uint32_t recno; > uint32_t system_flags; > uint32_t user_flags[4]; > unsigned int isseen:1; > unsigned int isrecent:1; > }; > > Which is 8 + 8 + 4 + 4 + 4 + 32 + (roundup) => 64 bytes per message. > > So a million messages required 64 megabytes of RAM. > So, on a 64GB machine, you can only handle 1000 users. That's not enough, plus loading that 64MB off disk is expensive in IOPs , and we're not using local disk, so transfer from one machine to another. And we have accounts with 10M+ messages, if the user happens to try to sort their All Mail folder, they could seriously impact the performance of other users on that box. > > The more interesting issue of course is populating the new details fast. > Offlineimap does: > > FETCH 1:* (UID INTERNALDATE FLAGS) > > So the only question is - do you store INTERNALDATE in an easily fetchable > location? > offlineimap hasn't done that in a couple years, since we asked them to stop doing it (just confirmed that with the current github source). That data for us requires loading the full meta-data for the message (ie, ENVELOPE level response). offlineimap doesn't actually use the information, so it was just consuming resources for no reason. No other client made that request. If more clients did request it, we'd need to make the data easier to access. > > Cyrus USED to not store it in the index, so you had to fetch and parse the > date header from the cache. That sucked. Now it's in cyrus.index which is > 128 bytes per message, so reads in fast, even for "cold" users. > I don't know if cyrus.index is a flat file or what, but re-writing large files isn't cheap. As you go up the ladder from a flat file to a btree to a generic "db" like table where you need to deserialize each row... it adds up. Brandon --0015175d00daaa2ef004e105c6fe Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Sun, Jul 7, 2013 at 4:47 AM, Bron Gondwana <= ;brong@fastmail.fm> wrote:
On Fri, May 10, 2013, at 07:53 AM, Brandon Long= wrote:
- Any pl= ans for support of the SORT extensions?
=A0
We have only the single SORT order in everything we do, so no. =A0Agai= n, we can't load the entire folder into memory just to SORT it on the s= erver, and we're not going to pre-compute and store each possible order= . =A0You'll note there is only the one order in all of the Gmail interf= aces. =A0Our marketing would say, don't sort, search!
=A0
I'm actually really surprised at this.=A0 In Cyrus we worked= on the assumption that a mailbox might have a million messages.=A0 We use = this data structure for the in-memory index state:
=A0
struct index_map {
=A0=A0=A0 modseq_t modseq;
=A0=A0=A0 modseq_t told_modseq;
=A0=A0=A0 uint32_t uid;
=A0=A0=A0 uint32_t recno;
=A0=A0=A0 uint32_t system_flags;
=A0=A0=A0 uint32_t user_flags[4];
=A0=A0=A0 unsigned int isseen:1;
=A0=A0=A0 unsigned int isrecent:1;
};
=A0
Which is 8 + 8 + 4 + 4 + 4 + 32 + (roundup) =3D> 64 bytes per messa= ge.
=A0
So a million messages required 64 megabytes of RAM.

So, on a 64GB machine, you can only handle 10= 00 users. =A0That's not enough, plus loading that 64MB off disk is expe= nsive in IOPs , and we're not using local disk, so transfer from one ma= chine to another.

And we have accounts with 10M+ messages, if the user ha= ppens to try to sort their All Mail folder, they could seriously impact the= performance of other users on that box.
=A0
=A0
The more interesting issue of course is populating the new details fas= t.=A0 Offlineimap does:
=A0
FETCH 1:* (UID INTERNALDATE FLAGS)
=A0
So the only question is - do you store INTERNALDATE in an easily fetch= able location?

offlineimap = hasn't done that in a couple years, since we asked them to stop doing i= t (just confirmed that with the current github source). That data for us re= quires loading the full meta-data for the message (ie, ENVELOPE level respo= nse). =A0offlineimap doesn't actually use the information, so it was ju= st consuming resources for no reason. =A0No other client made that request.=

If more clients did request it, we'd need to make t= he data easier to access.
=A0
=A0
Cyrus USED to not store it in the index, so you had to fetch and parse= the date header from the cache.=A0 That sucked.=A0 Now it's in cyrus.i= ndex which is 128 bytes per message, so reads in fast, even for "cold&= quot; users.

I don't know if cyrus.index is a flat = file or what, but re-writing large files isn't cheap. =A0As you go up t= he ladder from a flat file to a btree to a generic "db" like tabl= e where you need to deserialize each row... it adds up.

Brandon=A0
--0015175d00daaa2ef004e105c6fe-- From fatkudu@gmail.com Thu Jul 11 07:30:43 2013 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 6B8D521F99A8 for ; Thu, 11 Jul 2013 07:30:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] 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 BlgwRBs6tvlQ for ; Thu, 11 Jul 2013 07:30:42 -0700 (PDT) Received: from mail-qe0-x231.google.com (mail-qe0-x231.google.com [IPv6:2607:f8b0:400d:c02::231]) by ietfa.amsl.com (Postfix) with ESMTP id 8856721F842A for ; Thu, 11 Jul 2013 07:30:42 -0700 (PDT) Received: by mail-qe0-f49.google.com with SMTP id cz11so4390164qeb.22 for ; Thu, 11 Jul 2013 07:30:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:date:message-id:subject:from:to:content-type; bh=AlancjUAACXvuqPZMWc54jU52kwYg1/6ICX3NFpPgwA=; b=IRf4Ld5PpQzY7wW4nwnCRimzcVwQ4ZcWygnVptpd6hjPlaJYC7Bathl9eNBPjy8LNp KnxhkyU0EpYPnaujqTJqoRyIQqJPl8y4soYLIdCGLSbW8BLkZBGmLG0pmqU3PcpUmmX+ lisOS3dx5XFbv1FB80Q86ofo1abYuJJooAYkeVoH5wpdEkWSyTXwOwcEzk68ULx3XRwm fnCeJ3V5uEs++puueJ8VjBvKdlefF8tHE5o9SU9kad1cHqPgILMI0/0HX8j9uNjOvhuS AVxxuqEKZvRN1Hf8DiIUqNjHkejR/Mu/wONmRViuSRqC2ApNxeEZbZPsS67vCdPjyvV+ wxmw== MIME-Version: 1.0 X-Received: by 10.224.127.73 with SMTP id f9mr32857960qas.4.1373553031235; Thu, 11 Jul 2013 07:30:31 -0700 (PDT) Received: by 10.49.104.131 with HTTP; Thu, 11 Jul 2013 07:30:31 -0700 (PDT) Date: Thu, 11 Jul 2013 15:30:31 +0100 Message-ID: From: Gren Elliot To: imapext@ietf.org Content-Type: multipart/alternative; boundary=001a11c2bcf281ccdf04e13d3c46 X-Mailman-Approved-At: Thu, 11 Jul 2013 15:33:27 -0700 Subject: [imapext] Minor error in description of example 15 in draft-ietf-qresync-rfc4551bis-02 X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: fatkudu@gmail.com List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jul 2013 14:30:43 -0000 --001a11c2bcf281ccdf04e13d3c46 Content-Type: text/plain; charset=UTF-8 Hi, Near the end of section 3.4 in draft-ietf-qresync-rfc4551bis-02, there is this text: C: a SEARCH MODSEQ "/flags/\\draft" all 620162338 S: * SEARCH 2 5 6 7 11 12 18 19 20 23 (MODSEQ 917162500) S: a OK Search complete In the above example, the message numbers of any messages containing the string "IMAP4" in the "value" attribute of the "/comment" entry and having a mod-sequence equal to or greater than 620162338 for the "\Draft" flag are returned in the search results. The example SEARCH command doesn't actually mention "IMAP4" or "/comment". Either a longer example is needed or the text could be changed to something like: In the above example, the message numbers of any messages having a mod-sequence equal to or greater than 620162338 for the "\Draft" flag are returned in the search results. Regards, Gren --001a11c2bcf281ccdf04e13d3c46 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

Near the end of section 3.4 in draft= -ietf-qresync-rfc4551bis-02, there is this text:

   =
C: a SEARCH MODSEQ "/flags/\\draft" all 620162338
   S: * SEARCH 2 5 6 7 11 12 18 19 20 23 (MODSEQ 917162500)
   S: a OK Search complete

   In the above example, the message numbers of any messages containing
   the string "IMAP4" in the "value" attribute of the &=
quot;/comment" entry
   and having a mod-sequence equal to or greater than 620162338 for the
   "\Draft" flag are returned in the search results.

The example SEARCH command doesn't actually mention &q=
uot;IMAP4" or "/comment".
Either a longer example is need=
ed or the text could be changed to something like:


   In the above example, the message numbers of any messages having a <=
br>   mod-sequence equal to or greater than 620162338 for the "\Draft&=
quot; flag are
  =C2=A0returned in the search results.


Regards,
Gren

<= br>
--001a11c2bcf281ccdf04e13d3c46-- From fatkudu@gmail.com Fri Jul 12 02:05:09 2013 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 EE1BF21F9E54 for ; Fri, 12 Jul 2013 02:05:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] 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 dRoybJXcvGGb for ; Fri, 12 Jul 2013 02:05:09 -0700 (PDT) Received: from mail-qc0-x235.google.com (mail-qc0-x235.google.com [IPv6:2607:f8b0:400d:c01::235]) by ietfa.amsl.com (Postfix) with ESMTP id A825321F9F17 for ; Fri, 12 Jul 2013 02:05:07 -0700 (PDT) Received: by mail-qc0-f181.google.com with SMTP id u12so4800091qcx.26 for ; Fri, 12 Jul 2013 02:05:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:date:message-id:subject:from:to:content-type; bh=zwPY50F4bqMh9lshwFvI/cgePcr1ISCbH0JFm+RfvYY=; b=GIESnJFj9MObpzWPx2dhUQAFKi87mRi5LXRGhgko5hwrELuYdXtMs7/w2+jJ10aOAU Gnzpbwp2qjXJUAvJHEeUrKEBCpaq2lEMoJaXxMOlq61CUKXr/6fB8ikU8t4cIIuJhDUK x0KAF8lQ9eh39lIqMws1Vh3Ncw8bX53qHjIxiLQ/xJA5tLhV6Yn1b/VgDiBVVUnJohSs Ki6/Q/ABVxhmtUx/CJYHSuES2h8/lZrSYW8fkxWrCGm7w+3VgC0PcDHyXHGuSmhFGZ/N 9irdtca73ekUSIx/7ObMh5Dep3jS3P7JP6XuyLXMth05QugcL9E6yfqnzzRBnk67DMaa neSA== MIME-Version: 1.0 X-Received: by 10.49.12.11 with SMTP id u11mr34567571qeb.21.1373619907175; Fri, 12 Jul 2013 02:05:07 -0700 (PDT) Received: by 10.49.104.131 with HTTP; Fri, 12 Jul 2013 02:05:07 -0700 (PDT) Date: Fri, 12 Jul 2013 10:05:07 +0100 Message-ID: From: Gren Elliot To: imapext@ietf.org Content-Type: multipart/alternative; boundary=047d7b6dc1209fab0004e14cce4a Subject: [imapext] Minor error in description of example 15 in draft-ietf-qresync-rfc4551bis-02 X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: fatkudu@gmail.com List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jul 2013 09:05:10 -0000 --047d7b6dc1209fab0004e14cce4a Content-Type: text/plain; charset=UTF-8 Hi, Near the end of section 3.4 in draft-ietf-qresync-rfc4551bis- 02, there is this text: C: a SEARCH MODSEQ "/flags/\\draft" all 620162338 S: * SEARCH 2 5 6 7 11 12 18 19 20 23 (MODSEQ 917162500) S: a OK Search complete In the above example, the message numbers of any messages containing the string "IMAP4" in the "value" attribute of the "/comment" entry and having a mod-sequence equal to or greater than 620162338 for the "\Draft" flag are returned in the search results. The example SEARCH command doesn't actually mention "IMAP4" or "/comment". Either a longer example is needed or the text could be changed to something like: In the above example, the message numbers of any messages having a mod-sequence equal to or greater than 620162338 for the "\Draft" flag are returned in the search results. Regards, Gren --047d7b6dc1209fab0004e14cce4a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

Near the end of section 3.4 in draft-ietf-qresync-rfc= 4551bis-
02, there is this text:

   C: a SEARCH=
 MODSEQ "/flags/\\draft" all 620162338
   S: * SEARCH 2 5 6 7 11 12 18 19 20 23 (MODSEQ 917162500)
   S: a OK Search complete

   In the above example, the message numbers of any messages containing
   the string "IMAP4" in the "value" attribute of the &=
quot;/comment" entry
   and having a mod-sequence equal to or greater than 620162338 for the
   "\Draft" flag are returned in the search results.

The example SEARCH command doesn't actually mention "IMAP4&q=
uot; or "/comment".
Either a longer example is needed or the t=
ext could be changed to something like:


   In the above example, the message numbers of any messages having a <=
br>   mod-sequence equal to or greater than 620162338 for the "\Draft&=
quot; flag are
  =C2=A0returned in the search results.


Regards,
Gren

--047d7b6dc1209fab0004e14cce4a-- From alexey.melnikov@isode.com Fri Jul 12 06:10:08 2013 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 8CA2021E8053 for ; Fri, 12 Jul 2013 06:10:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.831 X-Spam-Level: X-Spam-Status: No, score=-102.831 tagged_above=-999 required=5 tests=[AWL=-0.232, BAYES_00=-2.599, 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 gTG7hBDDJ8MV for ; Fri, 12 Jul 2013 06:10:03 -0700 (PDT) Received: from statler.isode.com (statler.isode.com [62.3.217.254]) by ietfa.amsl.com (Postfix) with ESMTP id 4C98921F9DB8 for ; Fri, 12 Jul 2013 06:10:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1373634601; d=isode.com; s=selector; i=@isode.com; bh=mBUd4YuQUGPLtcg7RpHnQWONogb7fqKfPelKCeOIpT8=; 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=BbxQanZLtoQCfEXKvBPEEwu4SpzXSvBtOUJrd0sugcNzhgbtCT0dgse7VFRTJ5n28qnf3U 8jEa15MbYYg7a4M2SzRL12e3/dI0gUZyr0dV25cK++1pPXZJBgHZhsJ00dS5DRm1aZUWF7 KoNpPXbqiUw4xFw0DGZF1j3/iB9GpW4=; Received: from [172.16.1.29] (shiny.isode.com [62.3.217.250]) by statler.isode.com (submission channel) via TCP with ESMTPA id ; Fri, 12 Jul 2013 14:10:01 +0100 Message-ID: <51DFDF98.5020902@isode.com> Date: Fri, 12 Jul 2013 11:51:04 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 To: "imapext@ietf.org" MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [imapext] Non-existent SPECIAL-USE mailboxes X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jul 2013 13:10:08 -0000 Hi, My server doesn't create SPECIAL-USE mailboxes (other than INBOX), but it has their names preconfigured. So what should it return for a special use mailbox which is not created yet? Should it omit it or return it with \NonExistent attribute? I.e., if, for example, Junk doesn't exist, should the server return: f list (special-use) "" * * LIST (\Drafts) "/" Drafts * LIST (\Sent) "/" Sent * LIST (\Trash) "/" Trash f OK LIST Completed or f list (special-use) "" * * LIST (\Drafts) "/" Drafts * LIST (\Junk \NonExistent) "/" Junk * LIST (\Sent) "/" Sent * LIST (\Trash) "/" Trash f OK LIST Completed ? I am also curious about whether clients can handle \NonExistent in this case and use it as a hint that such mailbox should be created. Best Regards, Alexey From tss@iki.fi Fri Jul 12 06:17:43 2013 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 5573221E809A for ; Fri, 12 Jul 2013 06:17:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i+tqZtzXeyKj for ; Fri, 12 Jul 2013 06:17:37 -0700 (PDT) Received: from dovecot.org (dovecot.org [193.210.130.67]) by ietfa.amsl.com (Postfix) with ESMTP id 69D3C21E809C for ; Fri, 12 Jul 2013 06:17:37 -0700 (PDT) Received: from [192.168.10.100] (cs181255018.pp.htv.fi [82.181.255.18]) by dovecot.org (Postfix) with ESMTP id B16F41AE8786; Fri, 12 Jul 2013 16:17:35 +0300 (EEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Timo Sirainen In-Reply-To: <51DFDF98.5020902@isode.com> Date: Fri, 12 Jul 2013 16:17:35 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <51DFDF98.5020902@isode.com> To: Alexey Melnikov X-Mailer: Apple Mail (2.1508) Cc: "imapext@ietf.org" Subject: Re: [imapext] Non-existent SPECIAL-USE mailboxes X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jul 2013 13:17:43 -0000 On 12.7.2013, at 13.51, Alexey Melnikov = wrote: > My server doesn't create SPECIAL-USE mailboxes (other than INBOX), but = it has their names preconfigured. So what should it return for a special = use mailbox which is not created yet? Should it omit it or return it = with \NonExistent attribute? I don't think it should return it with \NonExistent. Seems like the = worst of all possibilities. Most clients will probably show it similarly = to \NoSelect (especially since \Nonexistent is LISTEXT-only), without = understanding what it should be used for. With Dovecot you can specify a SPECIAL-USE folder with or without = autocreation. Without autocreate it isn't visible unless the client = actually creates it. I think this is something some admins want to = enable and some don't.. From barryleiba.mailing.lists@gmail.com Sat Jul 13 05:51:31 2013 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 A62D021F9C8F for ; Sat, 13 Jul 2013 05:51:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.153 X-Spam-Level: X-Spam-Status: No, score=-101.153 tagged_above=-999 required=5 tests=[AWL=-0.842, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, SARE_HTML_USL_OBFU=1.666, 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 3KUceO0wLTNF for ; Sat, 13 Jul 2013 05:51:31 -0700 (PDT) Received: from mail-vb0-x22e.google.com (mail-vb0-x22e.google.com [IPv6:2607:f8b0:400c:c02::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 1443E21F9C8D for ; Sat, 13 Jul 2013 05:51:30 -0700 (PDT) Received: by mail-vb0-f46.google.com with SMTP id 10so2188738vbe.5 for ; Sat, 13 Jul 2013 05:51:30 -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=ndpjBBvnxca/bkGrug7BOWL+nT5QfSmm9sa/gjvpMJ8=; b=uyf3wwY+crxWVqjtXvbKdab6pTtcEG3lSa55epKNcPc9pYLd+Y750eOEY/A6QjmzRq PPq2x+HEeLvm6pwHGSnkZ7JNuEYw2uDI14pTF5HCksjMWHGvTp3BBlp/yht42z93bkFu zF5t7enktJ95hAC4j1amW11gwdLYe4JzAJEtezLLRCkU0yg5jPUWmnkt7A5omAlM5AQN bMZvDA4w8wePlebYQWW5YStqX2HaM3/EdBvH323lcT0oOMP5Quq9+4tizjdRifMhfKvJ g+UeUmEuljm/fOwtmSAfx0bAVXuB4fLEQZIZxxc4oT3yllWUIUcbLPlrxDSXpvtDc8TJ NnDQ== MIME-Version: 1.0 X-Received: by 10.52.165.239 with SMTP id zb15mr22041569vdb.44.1373719890520; Sat, 13 Jul 2013 05:51:30 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.58.137.227 with HTTP; Sat, 13 Jul 2013 05:51:30 -0700 (PDT) In-Reply-To: <51DFDF98.5020902@isode.com> References: <51DFDF98.5020902@isode.com> Date: Sat, 13 Jul 2013 08:51:30 -0400 X-Google-Sender-Auth: sS900c7RlZfQUEuG3mEjCe3znTE Message-ID: From: Barry Leiba To: Alexey Melnikov Content-Type: multipart/alternative; boundary=001a11c24eb0187bb104e16416f4 Cc: "imapext@ietf.org" Subject: Re: [imapext] Non-existent SPECIAL-USE mailboxes 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, 13 Jul 2013 12:51:31 -0000 --001a11c24eb0187bb104e16416f4 Content-Type: text/plain; charset=ISO-8859-1 The intent was the former: if there is no mailbox with a particular attribute, just don't show it. Barry On Friday, July 12, 2013, Alexey Melnikov wrote: > Hi, > My server doesn't create SPECIAL-USE mailboxes (other than INBOX), but it > has their names preconfigured. So what should it return for a special use > mailbox which is not created yet? Should it omit it or return it with > \NonExistent attribute? > > I.e., if, for example, Junk doesn't exist, should the server return: > > f list (special-use) "" * > * LIST (\Drafts) "/" Drafts > * LIST (\Sent) "/" Sent > * LIST (\Trash) "/" Trash > f OK LIST Completed > > or > > f list (special-use) "" * > * LIST (\Drafts) "/" Drafts > * LIST (\Junk \NonExistent) "/" Junk > * LIST (\Sent) "/" Sent > * LIST (\Trash) "/" Trash > f OK LIST Completed > > ? > > I am also curious about whether clients can handle \NonExistent in this > case and use it as a hint that such mailbox should be created. > > Best Regards, > Alexey > > ______________________________**_________________ > imapext mailing list > imapext@ietf.org > https://www.ietf.org/mailman/**listinfo/imapext > --001a11c24eb0187bb104e16416f4 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable The intent was the former: if there is no mailbox with a particular attribu= te, just don't show it.

Barry

On= Friday, July 12, 2013, Alexey Melnikov wrote:
Hi,
My server doesn't create SPECIAL-USE mailboxes (other than INBOX), but = it has their names preconfigured. So what should it return for a special us= e mailbox which is not created yet? Should it omit it or return it with \No= nExistent attribute?

I.e., if, for example, Junk doesn't exist, should the server return:
f list (special-use) "" *
* LIST (\Drafts) "/" Drafts
* LIST (\Sent) "/" Sent
* LIST (\Trash) "/" Trash
f OK LIST Completed

or

f list (special-use) "" *
* LIST (\Drafts) "/" Drafts
* LIST (\Junk \NonExistent) "/" Junk
* LIST (\Sent) "/" Sent
* LIST (\Trash) "/" Trash
f OK LIST Completed

?

I am also curious about whether clients can handle \NonExistent in this cas= e and use it as a hint that such mailbox should be created.

Best Regards,
Alexey

_______________________________________________
imapext mailing list
imapext@ietf.org
https://www.ietf.org/mailman/listinfo/imapext
--001a11c24eb0187bb104e16416f4-- From alexey.melnikov@isode.com Mon Jul 15 03:28:20 2013 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 5109521F9EC1 for ; Mon, 15 Jul 2013 03:28:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.731 X-Spam-Level: X-Spam-Status: No, score=-102.731 tagged_above=-999 required=5 tests=[AWL=-0.133, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 jiu-N4MPmgks for ; Mon, 15 Jul 2013 03:28:15 -0700 (PDT) Received: from statler.isode.com (statler.isode.com [62.3.217.254]) by ietfa.amsl.com (Postfix) with ESMTP id 1FBB121F9EDF for ; Mon, 15 Jul 2013 03:28:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1373884081; d=isode.com; s=selector; i=@isode.com; bh=iA1BKLbHQrcn/osDrYtGgfrP2JArPzGUAHQTi1XPRk0=; 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=mDVgoVeJcbhlCtnU4Ls0jh96VKGQYvnROag4oS+KNLDAjvbIae5KPkrNWTxDrfJ5JZcWZM B1Po4BPB6pVKPh2pCOmGleeKvqdZeZqa1xIAOTOoMlGyVlDYNhwPDtXw9nQMwNzJyPc6IJ hyZL7gbmtqcphlmlfPMnMdD9YxF8Cp4=; Received: from [172.16.1.29] (shiny.isode.com [62.3.217.250]) by statler.isode.com (submission channel) via TCP with ESMTPA id ; Mon, 15 Jul 2013 11:28:01 +0100 Message-ID: <51E3CECB.7020006@isode.com> Date: Mon, 15 Jul 2013 11:28:27 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 To: Barry Leiba References: <51DFDF98.5020902@isode.com> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------050604000305000404050008" Cc: "imapext@ietf.org" Subject: Re: [imapext] Non-existent SPECIAL-USE mailboxes 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, 15 Jul 2013 10:28:20 -0000 This is a multi-part message in MIME format. --------------050604000305000404050008 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 13/07/2013 13:51, Barry Leiba wrote: > The intent was the former: if there is no mailbox with a particular > attribute, just don't show it. So basically there is no way for the server to indicate that it hasn't pre-created a special use mailbox, but if the client wants one it should use a particular name? I am trying to avoid pre-creating mailboxes. > Barry > > On Friday, July 12, 2013, Alexey Melnikov wrote: > > Hi, > My server doesn't create SPECIAL-USE mailboxes (other than INBOX), > but it has their names preconfigured. So what should it return for > a special use mailbox which is not created yet? Should it omit it > or return it with \NonExistent attribute? > > I.e., if, for example, Junk doesn't exist, should the server return: > > f list (special-use) "" * > * LIST (\Drafts) "/" Drafts > * LIST (\Sent) "/" Sent > * LIST (\Trash) "/" Trash > f OK LIST Completed > > or > > f list (special-use) "" * > * LIST (\Drafts) "/" Drafts > * LIST (\Junk \NonExistent) "/" Junk > * LIST (\Sent) "/" Sent > * LIST (\Trash) "/" Trash > f OK LIST Completed > > ? > > I am also curious about whether clients can handle \NonExistent in > this case and use it as a hint that such mailbox should be created. > > Best Regards, > Alexey > --------------050604000305000404050008 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 13/07/2013 13:51, Barry Leiba wrote:
The intent was the former: if there is no mailbox with a particular attribute, just don't show it.
So basically there is no way for the server to indicate that it hasn't pre-created a special use mailbox, but if the client wants one it should use a particular name? I am trying to avoid pre-creating mailboxes.

Barry

On Friday, July 12, 2013, Alexey Melnikov wrote:
Hi,
My server doesn't create SPECIAL-USE mailboxes (other than INBOX), but it has their names preconfigured. So what should it return for a special use mailbox which is not created yet? Should it omit it or return it with \NonExistent attribute?

I.e., if, for example, Junk doesn't exist, should the server return:

f list (special-use) "" *
* LIST (\Drafts) "/" Drafts
* LIST (\Sent) "/" Sent
* LIST (\Trash) "/" Trash
f OK LIST Completed

or

f list (special-use) "" *
* LIST (\Drafts) "/" Drafts
* LIST (\Junk \NonExistent) "/" Junk
* LIST (\Sent) "/" Sent
* LIST (\Trash) "/" Trash
f OK LIST Completed

?

I am also curious about whether clients can handle \NonExistent in this case and use it as a hint that such mailbox should be created.

Best Regards,
Alexey

--------------050604000305000404050008-- From barryleiba@gmail.com Mon Jul 15 05:55:06 2013 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 A261011E80D3 for ; Mon, 15 Jul 2013 05:55:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.977 X-Spam-Level: X-Spam-Status: No, score=-101.977 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001, 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 gRkbxAjtlQyJ for ; Mon, 15 Jul 2013 05:55:06 -0700 (PDT) Received: from mail-qa0-x22e.google.com (mail-qa0-x22e.google.com [IPv6:2607:f8b0:400d:c00::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 5AA2711E80F1 for ; Mon, 15 Jul 2013 05:55:02 -0700 (PDT) Received: by mail-qa0-f46.google.com with SMTP id bn16so1550843qab.19 for ; Mon, 15 Jul 2013 05:54:58 -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=lu4E9C5snSvICkA2nDwtCFcHz63TLmaNGdrNcOydgfg=; b=kWPkMGHP1QhJ4tQux3ALYtPz9E7fAzHnqgAvhZZnpDD9ZPobPSZUkEtPf9fg/WGVQP JsDUUGB+GetjIX/vCWUDljQd94WuxAMhJfL+hOkle5PSMKPcUkPR/hsjCGkO0tmUKZ3T l8ZvQtB/RrUXf96XNB22nvdwCHZ7SflBaltl3U4av9Qtmrc+Mc3u4nWIPV/EIgP+UWix pbZLdf4drqK+tTNVXckihnoJOHqDc/xj70I8L3OTYZymMKGApducqIJSmS/P9Zn8r63v KiFmMn/6fsWMezdWCaciDe22zNHmFMs3c9khF+7Cx+Xc814FSlWfpvvBYiqN8k558akH NQsg== MIME-Version: 1.0 X-Received: by 10.224.115.5 with SMTP id g5mr52398515qaq.53.1373892897977; Mon, 15 Jul 2013 05:54:57 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.224.116.202 with HTTP; Mon, 15 Jul 2013 05:54:57 -0700 (PDT) In-Reply-To: <51E3CECB.7020006@isode.com> References: <51DFDF98.5020902@isode.com> <51E3CECB.7020006@isode.com> Date: Mon, 15 Jul 2013 08:54:57 -0400 X-Google-Sender-Auth: 6eTmOw3IQ6_-QRvGzYS3D96HgSA Message-ID: From: Barry Leiba To: Alexey Melnikov Content-Type: text/plain; charset=ISO-8859-1 Cc: "imapext@ietf.org" Subject: Re: [imapext] Non-existent SPECIAL-USE mailboxes 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, 15 Jul 2013 12:55:06 -0000 >> The intent was the former: if there is no mailbox with a particular >> attribute, just don't show it. > > So basically there is no way for the server to indicate that it hasn't > pre-created a special use mailbox, but if the client wants one it should use > a particular name? I am trying to avoid pre-creating mailboxes. Right. If the client wants a mailbox with a particular special use, and none exists, the client can just create it. The server can accept that or fail it. Why do you care about the particular name? The whole *point* of the special-use attribute is to decouple the mailbox name from the special use. Barry From arnt@gulbrandsen.priv.no Mon Jul 15 13:25:59 2013 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 7502621E817D for ; Mon, 15 Jul 2013 13:25:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 xkU+q9bFZaCd for ; Mon, 15 Jul 2013 13:25:58 -0700 (PDT) Received: from strange.aox.org (strange.aox.org [IPv6:2001:4d88:100c::1]) by ietfa.amsl.com (Postfix) with ESMTP id 08C3F21E816D for ; Mon, 15 Jul 2013 13:25:56 -0700 (PDT) Received: from fri.gulbrandsen.priv.no (localhost [127.0.0.1]) by strange.aox.org (Postfix) with ESMTP id 68948FA00F8; Mon, 15 Jul 2013 20:25:53 +0000 (UTC) Received: from arnt@gulbrandsen.priv.no by fri.gulbrandsen.priv.no (Archiveopteryx 3.1.4) with esmtpsa id 1373919952-3316-3312/12/31; Mon, 15 Jul 2013 20:25:52 +0000 User-Agent: Kaiten Mail In-Reply-To: <51E3CECB.7020006@isode.com> References: <51DFDF98.5020902@isode.com> <51E3CECB.7020006@isode.com> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=----FKU3JSLNDPDO9QW0IKHRS8E8M84YAH From: Arnt Gulbrandsen Date: Mon, 15 Jul 2013 22:25:48 +0200 To: Alexey Melnikov , Barry Leiba Message-Id: <0810a47b-d2bf-4723-9e3e-74e6c380b623@email.android.com> Cc: imapext@ietf.org Subject: Re: [imapext] Non-existent SPECIAL-USE mailboxes 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, 15 Jul 2013 20:25:59 -0000 ------FKU3JSLNDPDO9QW0IKHRS8E8M84YAH Content-Type: text/plain; charset=utf-8 Is there a non-negligible cost associated with pre-creation? Arnt ------FKU3JSLNDPDO9QW0IKHRS8E8M84YAH Content-Type: text/html; charset=utf-8

Is there a non-negligible cost associated with pre-creation?


Arnt ------FKU3JSLNDPDO9QW0IKHRS8E8M84YAH-- From tss@iki.fi Mon Jul 15 16:55:57 2013 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 5F0DA21E81AA for ; Mon, 15 Jul 2013 16:55:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kEqfDkrASzNn for ; Mon, 15 Jul 2013 16:55:51 -0700 (PDT) Received: from dovecot.org (dovecot.org [193.210.130.67]) by ietfa.amsl.com (Postfix) with ESMTP id 83B5921E81A5 for ; Mon, 15 Jul 2013 16:55:49 -0700 (PDT) Received: from [172.20.10.2] (37-136-201-229.nat.bb.dnainternet.fi [37.136.201.229]) by dovecot.org (Postfix) with ESMTP id 5A4951AE8786; Tue, 16 Jul 2013 02:55:43 +0300 (EEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Timo Sirainen In-Reply-To: <0810a47b-d2bf-4723-9e3e-74e6c380b623@email.android.com> Date: Tue, 16 Jul 2013 01:55:41 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <51DFDF98.5020902@isode.com> <51E3CECB.7020006@isode.com> <0810a47b-d2bf-4723-9e3e-74e6c380b623@email.android.com> To: Arnt Gulbrandsen X-Mailer: Apple Mail (2.1508) Cc: Alexey Melnikov , Barry Leiba , imapext@ietf.org Subject: Re: [imapext] Non-existent SPECIAL-USE mailboxes 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, 15 Jul 2013 23:55:57 -0000 On 15.7.2013, at 22.25, Arnt Gulbrandsen = wrote: > Is there a non-negligible cost associated with pre-creation? Dovecot v2.1+ "autocreates" the autocreated mailboxes (special-use or = not) by simply showing them in the LIST response, not by physically = creating anything at all on the filesystem. They are not physically = created until SELECT/EXAMINE/STATUS is used on them. If the cost is an = issue, I don't see why all servers couldn't create a similar feature.. From alexey.melnikov@isode.com Thu Jul 25 06:38:38 2013 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 EB37021F91CB for ; Thu, 25 Jul 2013 06:38:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7gMSH8sOVQWU for ; Thu, 25 Jul 2013 06:38:34 -0700 (PDT) Received: from statler.isode.com (statler.isode.com [62.3.217.254]) by ietfa.amsl.com (Postfix) with ESMTP id ACAB621F9AA7 for ; Thu, 25 Jul 2013 06:38:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1374759511; d=isode.com; s=selector; i=@isode.com; bh=D4kepRs/YHfSoxVnCD2UXzwxA7ETEyL7UvLrUqqrpMU=; 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=riHiH5rHu8RWfkJiMf6xvM5epGScSNqqflLlieLob7LdPWJS0Al6/aHAfPD4aIQeqn2FIe 97IG2b1hDZXBn9FZSaPWhascKdMCzQBBBNXTpwer1TXF0K7tlac1JVlwNjD3Rsz36vGi+Y ybzJw5yN/NQrjAAIiKcnSnSH1H4TWBU=; Received: from [172.16.1.29] (shiny.isode.com [62.3.217.250]) by statler.isode.com (submission channel) via TCP with ESMTPA id ; Thu, 25 Jul 2013 14:38:31 +0100 Message-ID: <51F12A57.2060605@isode.com> Date: Thu, 25 Jul 2013 14:38:31 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 To: "imapext@ietf.org" MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [imapext] Certificate checking in hosted IMAP environments (POSH BoF in Berlin) 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, 25 Jul 2013 13:38:39 -0000 Hi, IETF in Berlin is going to have a BOF session on POSH ("PKIX over Secure HTTP"). What people discovered in the XMPP community is that it's effectively impossible for those who operate XMPP services to obtain and offer proper (RFC6125-compliant) certificates for hosted domains. CAs won't give them out ("hey, you're hosting.example.net, not example.com"), customers won't upload their private keys (why would they?), and operators don't want those private keys anyway (liability avoidance). Matt Miller and Peter Saint-Andre describe the problem, mostly from an XMPP perspective, here: http://datatracker.ietf.org/doc/draft-miller-posh/ but this is easily extensible to other protocols. If you have any feedback on whether the same problem is relevant to IMAP deployments, please email me directly. Thank you, Alexey From blong@google.com Thu Jul 25 14:08:45 2013 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 6521021F9302 for ; Thu, 25 Jul 2013 14:08:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.311 X-Spam-Level: X-Spam-Status: No, score=-0.311 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, SARE_HTML_USL_OBFU=1.666] 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 QUSrYgICvXmi for ; Thu, 25 Jul 2013 14:08:44 -0700 (PDT) Received: from mail-ob0-x230.google.com (mail-ob0-x230.google.com [IPv6:2607:f8b0:4003:c01::230]) by ietfa.amsl.com (Postfix) with ESMTP id 9510421F9298 for ; Thu, 25 Jul 2013 14:08:44 -0700 (PDT) Received: by mail-ob0-f176.google.com with SMTP id v19so2597783obq.7 for ; Thu, 25 Jul 2013 14:08: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; bh=GPLsp7U41/rhQ8jH6uZD3zGLhYC79EP1wQN+z79DXjY=; b=mPrgfN/YN5zN7Ql8oLmPd03xGK1pbueXcRPUHWyThF7cCaJ8rGiVfekXWKbbuebRD7 AkrN5bNM4uYkI5IJGjUmDzJ3Z29l5LfKXYD3uHADGVON5LicB/J4vACTqi9xQ5s8KkLf UNl+YKN/JY2k6JC+KtcCMFsHdKPbzKWGoJnim3RTaQ9naSeV2RHogS0TfI2v7d3FqmCm Nz8yO3MzUeGbsFFGxJRnBFfktF430J76NFsCv7XxjnOEN+9V9mIJD3rIgYGGFo7mogiJ vPW0O3k1PjbbgrgaqcKQaC28f8P5QfTxwfw3p+VE6D4MHAd60VTx6hYrI/KN30O2ZHiw QkEA== 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-gm-message-state; bh=GPLsp7U41/rhQ8jH6uZD3zGLhYC79EP1wQN+z79DXjY=; b=Lx0O+7AL/BRPBZEUswGKetMThnfheVxH2tuWdhKXtOY+OcCQezAn5p6Dj6a1B16axS tMi+hsYaSiL1UAG2NoHzjs5iFjTr4pkZqRzFFLr2byGsRsMhZgOzSf0Hvpy9GzZIQQky GBw3FWE3wN+W2bATXbcDA7vPx5PkfBPI5tEi6GTAoVXn+LJ6UXM3TinnTRBEaxSZmw4o Zpg1B6teFvihJkNWnia++nvdlG44I+qyh4k6jORKtMsOn8rWG65LdNT9J1jyB55JOf82 LzX7sF4/ntAFIJ3perfdVyM91PX74WNBlnv3ptS0DLYVf1UKB2vqnc+5NCfHZuIVsM79 azXw== MIME-Version: 1.0 X-Received: by 10.50.111.104 with SMTP id ih8mr552582igb.28.1374786522990; Thu, 25 Jul 2013 14:08:42 -0700 (PDT) Received: by 10.64.55.70 with HTTP; Thu, 25 Jul 2013 14:08:42 -0700 (PDT) In-Reply-To: <51F12A57.2060605@isode.com> References: <51F12A57.2060605@isode.com> Date: Thu, 25 Jul 2013 14:08:42 -0700 Message-ID: From: Brandon Long To: Alexey Melnikov Content-Type: multipart/alternative; boundary=089e0149be5858763104e25c6ea4 X-Gm-Message-State: ALoCoQkEr1nR7t8nDwRpiCkJ8ZTHpeXBF/94dVLyILh+6IJSoKn0viEO6+lQqiv3hpE20jrS6C24TmjTevaJSwI18iwANEhlY7lAQcKOq0SkCd18FK6nzSSlGI7koXMIfIK/O9rgJMkbs72/MKUpFQK+NOVrhGHTUsvkwuhDlOKp4lCBvzzMGwaG5uRFnHTkZ7Nd8x8Vw+Jp Cc: "imapext@ietf.org" Subject: Re: [imapext] Certificate checking in hosted IMAP environments (POSH BoF in Berlin) 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, 25 Jul 2013 21:08:45 -0000 --089e0149be5858763104e25c6ea4 Content-Type: text/plain; charset=ISO-8859-1 We haven't seen this issue for imap/pop/smtp-msa, largely because we tend to offer these services on a subdomain, ie imap.example.com, and the customers are fine with providing a certificate for the sub-domain. Even for web cases, we have customers upload www.example.com keys to us as well. That doesn't make me opposed to some mechanism like the above. For outbound smtp, we don't see the issue because we do the mx lookup first, and then the ssl certificate would match the mx's hostnames instead of the domain on the email message, so the problem is actually validating the mx lookup results. Brandon On Thu, Jul 25, 2013 at 6:38 AM, Alexey Melnikov wrote: > Hi, > IETF in Berlin is going to have a BOF session on POSH ("PKIX over Secure > HTTP"). > > What people discovered in the XMPP community is that it's effectively > impossible for those who operate XMPP services to obtain and offer > proper (RFC6125-compliant) certificates for hosted domains. CAs won't > give them out ("hey, you're hosting.example.net, not example.com"), > customers won't upload their private keys (why would they?), and > operators don't want those private keys anyway (liability avoidance). > > Matt Miller and Peter Saint-Andre describe the problem, mostly from an > XMPP perspective, here: > > http://datatracker.ietf.org/**doc/draft-miller-posh/ > > but this is easily extensible to other protocols. > > If you have any feedback on whether the same problem is relevant to IMAP > deployments, please email me directly. > > Thank you, > Alexey > > ______________________________**_________________ > imapext mailing list > imapext@ietf.org > https://www.ietf.org/mailman/**listinfo/imapext > --089e0149be5858763104e25c6ea4 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
We haven't seen this issue for imap/pop/smtp-msa, larg= ely because we tend to offer these services on a subdomain, ie imap.example.com, and the customers are fine wi= th providing a certificate for the sub-domain.

Even for web cases, we have customers upload www.example.com keys to us as well.

<= /div>
That doesn't make me opposed to some mechanism like the above= .

For outbound smtp, we don't see the issue because w= e do the mx lookup first, and then the ssl certificate would match the mx&#= 39;s hostnames instead of the domain on the email message, so the problem i= s actually validating the mx lookup results.

Brandon


<= div class=3D"gmail_quote">On Thu, Jul 25, 2013 at 6:38 AM, Alexey Melnikov = <alexey.melnikov@isode.com> wrote:
Hi,
IETF in Berlin is going to have a BOF session on POSH ("PKIX over Secu= re HTTP").

What people discovered in the XMPP community is that it's effectively impossible for those who operate XMPP services to obtain and offer
proper (RFC6125-compliant) certificates for hosted domains. CAs won't give them out ("hey, you're hosting.example.net, not example.com"),
customers won't upload their private keys (why would they?), and
operators don't want those private keys anyway (liability avoidance).
Matt Miller and Peter Saint-Andre describe the problem, mostly from an XMPP= perspective, here:

http://datatracker.ietf.org/doc/draft-miller-posh/

but this is easily extensible to other protocols.

If you have any feedback on whether the same problem is relevant to IMAP de= ployments, please email me directly.

Thank you,
Alexey

_______________________________________________
imapext mailing list
imapext@ietf.org<= br> https://www.ietf.org/mailman/listinfo/imapext

--089e0149be5858763104e25c6ea4--