From alexey.melnikov@isode.com Mon Aug 12 05:09: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 8D9F021F9EDF for ; Mon, 12 Aug 2013 05:09:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.164 X-Spam-Level: X-Spam-Status: No, score=-101.164 tagged_above=-999 required=5 tests=[AWL=-0.054, BAYES_05=-1.11, 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 cNyB7dSazxLg for ; Mon, 12 Aug 2013 05:09:04 -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 5872F21F9A98 for ; Mon, 12 Aug 2013 04:56:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1376308569; d=isode.com; s=selector; i=@isode.com; bh=klzbDNVCGSNXIOW7g3Pk72ghkwz/bFRS/2ORaFmQ5o8=; 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=KyBDhz4ODTxQJRxsAMYLrZc/JPtIpByyVoXjCkU2KEKd8ePxTPoemAqdXw1mWnaCRR+Adk NlP5FcAA16jKuNQhU4NlGA95RioWDUf1PoPEqYrLHwAvda8iE5BdIQZ03AHgph0hl0Ithl gVGAo/L74Uvr01dkXJNpuARd0a4n90c=; Received: from [172.16.1.29] (shiny.isode.com [62.3.217.250]) by waldorf.isode.com (submission channel) via TCP with ESMTPA id ; Mon, 12 Aug 2013 12:56:09 +0100 Message-ID: <5208CD61.3070100@isode.com> Date: Mon, 12 Aug 2013 12:56:17 +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] CONDSTORE interaction with SORT/THREAD 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, 12 Aug 2013 12:09:06 -0000 Timo and Dan pointed out earlier that CONDSTORE/QRESYNC don't specify how they interact with SORT and THREAD. In particular, what kind of response should be used for requests like A001 SORT (DATE) UTF-8 MODSEQ 500 We have a couple of choices here and I would like to know what people's preferences are, in particular if people implement any particular choice already. For SORT that includes a MODSEQ search criterion, possible options are: 1). Use ESEARCH response (RFC 4731) to return MODSEQ for all matching messages and also extend it to return sorted results. (This can be potentially be used for SEARCH with MODSEQ search criterion as well). For example: * ESEARCH (TAG "A001") SORTED 3,4,1,2 MODSEQ 175 Here SORTED is similar to ALL, but it preserves the SORT order of matching messages. RFC 4731 already defines MODSEQ return item. 2). Extend SORT response in the same way CONDSTORE extended SEARCH response: * SORT 5 3 4 1 2 (MODSEQ 175) 3). Return 2 response: an ESEARCH with MODSEQ and a SORT: * SORT 5 3 4 1 2 * ESEARCH (TAG "A001") MODSEQ 175 (they can be returned in any order) I personally have a slight preference for choices #3/#1, as I don't want to prolifirate new variants of responses which are not ESEARCH based. Similarly, for THREAD: 1). Use ESEARCH response (RFC 4731) to return MODSEQ for all matching messages and also extend it to return threaded results. For example: * ESEARCH (TAG "A002") THREAD ((2)(3 6 (4 23)(44 7 96))) MODSEQ 909240921 2). Extend THREAD response in the same way CONDSTORE extended SEARCH response: * THREAD (2)(3 6 (4 23)(44 7 96)) (MODSEQ 909240921) 3). Return 2 response: a ESEARCH with MODSEQ and a THREAD: * SORT 5 3 4 1 2 * THREAD (2)(3 6 (4 23)(44 7 96)) * ESEARCH (TAG "A002") MODSEQ 909240921 Here again, I prefer choices #1/#3. If people implemented other choices, please let me know. From tss@iki.fi Mon Aug 12 06:36:32 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 DB59D11E80F3 for ; Mon, 12 Aug 2013 06:36:32 -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 ZkIjNunF-6+U for ; Mon, 12 Aug 2013 06:36:24 -0700 (PDT) Received: from dovecot.org (dovecot.org [193.210.130.67]) by ietfa.amsl.com (Postfix) with ESMTP id A8EE221F9B25 for ; Mon, 12 Aug 2013 06:27:58 -0700 (PDT) Received: from [10.217.1.101] (vfw03.dovecot.fi [88.194.145.100]) by dovecot.org (Postfix) with ESMTP id 66ABF1AE881D; Mon, 12 Aug 2013 16:27:49 +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: <5208CD61.3070100@isode.com> Date: Mon, 12 Aug 2013 16:27:47 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5208CD61.3070100@isode.com> To: Alexey Melnikov X-Mailer: Apple Mail (2.1508) Cc: "imapext@ietf.org" Subject: Re: [imapext] CONDSTORE interaction with SORT/THREAD 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, 12 Aug 2013 13:36:33 -0000 On 12.8.2013, at 14.56, Alexey Melnikov = wrote: > Timo and Dan pointed out earlier that CONDSTORE/QRESYNC don't specify = how they interact with SORT and THREAD. I don't remember, I guess it was a long time ago. > In particular, what kind of response should be used for requests like >=20 > A001 SORT (DATE) UTF-8 MODSEQ 500 >=20 > We have a couple of choices here and I would like to know what = people's preferences are, in particular if people implement any = particular choice already. >=20 > For SORT that includes a MODSEQ search criterion, possible options = are: >=20 > 1). Use ESEARCH response (RFC 4731) to return MODSEQ for all matching = messages and also extend it to return sorted results. (This can be = potentially be used for SEARCH with MODSEQ search criterion as well). = For example: >=20 > * ESEARCH (TAG "A001") SORTED 3,4,1,2 MODSEQ 175 >=20 > Here SORTED is similar to ALL, but it preserves the SORT order of = matching messages. > RFC 4731 already defines MODSEQ return item. This could be a nice new option, but I don't think MODSEQ parameter = alone should change the reply so radically. > 2). Extend SORT response in the same way CONDSTORE extended SEARCH = response: >=20 > * SORT 5 3 4 1 2 (MODSEQ 175) Dovecot has been returning this for last 4 years (since v1.2), so it's = already quite widely used.. I don't think I actually intended to add it, = the SEARCH and SORT code was just mostly shared and it just happened. So = this would be my recommendation. :) > I personally have a slight preference for choices #3/#1, as I don't = want to prolifirate new variants of responses which are not ESEARCH = based. One possibility would be to return #1, but only if some other new = parameter is used. That parameter could then also be used without = MODSEQ. It also wouldn't break with the existing Dovecot installations. > Similarly, for THREAD: >=20 > 1). Use ESEARCH response (RFC 4731) to return MODSEQ for all matching = messages and also extend it to return threaded results. For example: >=20 > * ESEARCH (TAG "A002") THREAD ((2)(3 6 (4 23)(44 7 96))) MODSEQ = 909240921 >=20 > Here again, I prefer choices #1/#3. With THREAD Dovecot doesn't return MODSEQ in any way. From jkt@flaska.net Mon Aug 12 06:39:28 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 2156821F9AD6 for ; Mon, 12 Aug 2013 06:39:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.904 X-Spam-Level: X-Spam-Status: No, score=-0.904 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, MIME_QP_LONG_LINE=1.396, 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 PZ2eFBQ0v+cr for ; Mon, 12 Aug 2013 06:39:27 -0700 (PDT) Received: from latimerie.flaska.net (latimerie.flaska.net [IPv6:2a02:2b88:2:1::4a7:333]) by ietfa.amsl.com (Postfix) with ESMTP id ACFD511E8105 for ; Mon, 12 Aug 2013 06:32:24 -0700 (PDT) Received: by latimerie.flaska.net (Postfix, from userid 1000) id 492F2607B1; Mon, 12 Aug 2013 15:32:22 +0200 (CEST) From: =?iso-8859-1?Q?Jan_Kundr=E1t?= To: Date: Mon, 12 Aug 2013 15:32:17 +0200 User-Agent: trojita/v0.3.93-263-g97e42ff; Qt/4.8.4; X11; Linux; MIME-Version: 1.0 Message-ID: <7bad458f-e05d-4df1-bbed-47190b8dbd16@flaska.net> In-Reply-To: <5208CD61.3070100@isode.com> References: <5208CD61.3070100@isode.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Subject: Re: [imapext] CONDSTORE interaction with SORT/THREAD 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, 12 Aug 2013 13:39:28 -0000 On Monday, 12 August 2013 13:56:17 CEST, Alexey Melnikov wrote: > 1). Use ESEARCH response (RFC 4731) to return MODSEQ for all=20 > matching messages and also extend it to return sorted results.=20 > (This can be potentially be used for SEARCH with MODSEQ search=20 > criterion as well). For example: > > * ESEARCH (TAG "A001") SORTED 3,4,1,2 MODSEQ 175 I've just re-read the relevant bits of RFC 4551 again. I have to admit I do=20= not understand the point of including the highest MODSEQ of the matching=20 messages under the MODSEQ key -- what is the use case for that? Sure, it's=20= in the RFC so we cannot change it now, but I'd like to understand the=20 motivation behind this. > Here SORTED is similar to ALL, but it preserves the SORT order=20 > of matching messages. > RFC 4731 already defines MODSEQ return item. Unless I'm missing something, the example response invents a non-existant=20 "SORTED" ESEARCH return value. RFC 5267 (CONTEXT=3D...) already defines the=20= ESORT extension and the ESORT command and how it uses the ESEARCH response=20= (some servers were broken and used to return an ESORT response, btw). The=20 result is passed as if it was triggered via the ESEARCH command, only in a=20= sorted form, so the correct return data are, IMHO: * ESEARCH (TAG "A001") ALL 3,4,1,2 MODSEQ 175 I'm also confused because the command asked for MODSEQ >=3D 500, but the=20 response claims that the highest MODSEQ of any matching messages is 175. > 2). Extend SORT response in the same way CONDSTORE extended SEARCH=20 response: > > * SORT 5 3 4 1 2 (MODSEQ 175) That would require a modification of the ABNF and as such it cannot be=20 introduced retroacitvely, right? > 3). Return 2 response: an ESEARCH with MODSEQ and a SORT: > > * SORT 5 3 4 1 2 > * ESEARCH (TAG "A001") MODSEQ 175 I realize this is about SORT, not SEARCH, but RFC 4466, section 2.6.1=20 contains a SHOULD saying that there should only be a SEARCH *or* an ESEARCH=20= response, not both. > I personally have a slight preference for choices #3/#1, as I=20 > don't want to prolifirate new variants of responses which are=20 > not ESEARCH based. Indeed, and for the reasons stated above, I prefer 1) after it's fixed to=20 use ALL instead of SORTED. > 1). Use ESEARCH response (RFC 4731) to return MODSEQ for all=20 > matching messages and also extend it to return threaded results.=20 > For example: > > * ESEARCH (TAG "A002") THREAD ((2)(3 6 (4 23)(44 7 96))) MODSEQ=20 909240921 I would love to have the THREAD return option for ESEARCH; in fact, I've=20 tried to introduce it in draft-kundrat-incthread [1]. It will help Trojita=20= understand the matching between commands and responses and therefore enable=20= better pipelining. With kind regards, Jan [1] http://tools.ietf.org/html/draft-kundrat-incthread-01#section-2.3.1 From no-reply=26=josef.andrysek@icewarp.com Mon Aug 12 12:00:21 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 3FBC821F9EDD for ; Mon, 12 Aug 2013 12:00:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.105 X-Spam-Level: ** X-Spam-Status: No, score=2.105 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.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 M1xv7u8OrMte for ; Mon, 12 Aug 2013 12:00:15 -0700 (PDT) Received: from server.icewarp.com (unknown [217.31.57.169]) by ietfa.amsl.com (Postfix) with ESMTP id 85AE821F9E47 for ; Mon, 12 Aug 2013 12:00:12 -0700 (PDT) Received: from ([12.22.58.30]) by server.icewarp.com (IceWarp 11.0.0 (2013-08-08) x64) with SMTP id 201308122100058731 for ; Mon, 12 Aug 2013 21:00:05 +0200 Date: Mon, 12 Aug 2013 21:00:05 +0200 From: "Josef Andrysek" To: Message-Id: <65b470662e973346e3fcebd66478c0a5-1124902914@server.icewarp.com> Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit Auto-Submitted: auto-replied Precedence: bulk Subject: [imapext] I'm not available X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Aug 2013 19:00:21 -0000 Hello, I'm sorry but I'm unavailable till 19.8.2013 In case of need please contact tonda@icewarp.com and he is going to forward your message to responsible person. Best Josef From alexey.melnikov@isode.com Tue Aug 13 09:57: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 5F02F21E80BA for ; Tue, 13 Aug 2013 09:57:56 -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 4RtcnSe+aTp8 for ; Tue, 13 Aug 2013 09:57:51 -0700 (PDT) Received: from statler.isode.com (statler.isode.com [62.3.217.254]) by ietfa.amsl.com (Postfix) with ESMTP id A861621E80B3 for ; Tue, 13 Aug 2013 09:57:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1376413064; d=isode.com; s=selector; i=@isode.com; bh=p0gFvnppeimrYWp7tdmZcPSOH0uOf5RmgFosiO8hUw4=; 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=dXg8aTYK6h6Q+oKzXQUrO5kBcIt8qIQxy+EdFZAK8W3Ew9xtYgXsjdeyzBS3J8Vs8Y/i8z j3rnBc30GHFruYMWjUJPrDib2K6QGD9LD5ykMlcQvaMnkkdFDWNSm5iQCzbOw5rHSGzRZ7 LW4mZxQmAg0rBHgsEk3VkH5bYdQb9ew=; 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, 13 Aug 2013 17:57:43 +0100 Message-ID: <520A658D.10409@isode.com> Date: Tue, 13 Aug 2013 17:57:49 +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: <5208CD61.3070100@isode.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] CONDSTORE interaction with SORT/THREAD 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, 13 Aug 2013 16:57:56 -0000 On 12/08/2013 14:27, Timo Sirainen wrote: > On 12.8.2013, at 14.56, Alexey Melnikov wrote: > >> Timo and Dan pointed out earlier that CONDSTORE/QRESYNC don't specify how they interact with SORT and THREAD. > I don't remember, I guess it was a long time ago. > >> In particular, what kind of response should be used for requests like >> >> A001 SORT (DATE) UTF-8 MODSEQ 500 >> >> We have a couple of choices here and I would like to know what people's preferences are, in particular if people implement any particular choice already. >> >> For SORT that includes a MODSEQ search criterion, possible options are: >> >> 1). Use ESEARCH response (RFC 4731) to return MODSEQ for all matching messages and also extend it to return sorted results. (This can be potentially be used for SEARCH with MODSEQ search criterion as well). For example: >> >> * ESEARCH (TAG "A001") SORTED 3,4,1,2 MODSEQ 175 >> >> Here SORTED is similar to ALL, but it preserves the SORT order of matching messages. >> RFC 4731 already defines MODSEQ return item. > This could be a nice new option, but I don't think MODSEQ parameter alone should change the reply so radically. > >> 2). Extend SORT response in the same way CONDSTORE extended SEARCH response: >> >> * SORT 5 3 4 1 2 (MODSEQ 175) > Dovecot has been returning this for last 4 years (since v1.2), so it's already quite widely used.. I don't think I actually intended to add it, the SEARCH and SORT code was just mostly shared and it just happened. So this would be my recommendation. :) While I dislike this option, I don't see a reason to break your implementation, as long as other common implementations didn't do something different... >> I personally have a slight preference for choices #3/#1, as I don't want to prolifirate new variants of responses which are not ESEARCH based. > One possibility would be to return #1, but only if some other new parameter is used. That parameter could then also be used without MODSEQ. It also wouldn't break with the existing Dovecot installations. Right. For example RESMODSEQ (it has the same semantics as MODSEQ SEARCH/SORT item, but causes ESEARCH response to be returned). >> Similarly, for THREAD: >> >> 1). Use ESEARCH response (RFC 4731) to return MODSEQ for all matching messages and also extend it to return threaded results. For example: >> >> * ESEARCH (TAG "A002") THREAD ((2)(3 6 (4 23)(44 7 96))) MODSEQ 909240921 >> >> Here again, I prefer choices #1/#3. > With THREAD Dovecot doesn't return MODSEQ in any way. Ok. Which option you prefer for THREAD+CONDSTORE? From alexey.melnikov@isode.com Tue Aug 13 10:01:46 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 1D77C21E808A for ; Tue, 13 Aug 2013 10:01:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.449 X-Spam-Level: X-Spam-Status: No, score=-102.449 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, 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 pvjAUbh39+C7 for ; Tue, 13 Aug 2013 10:01:41 -0700 (PDT) Received: from statler.isode.com (statler.isode.com [62.3.217.254]) by ietfa.amsl.com (Postfix) with ESMTP id 3AD8D21E811A for ; Tue, 13 Aug 2013 10:01:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1376413300; d=isode.com; s=selector; i=@isode.com; bh=x2OTjL+c7idxcEE/9Qc2R1O57V6LvG+XPpAhrIGeI4A=; 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=OEfxXuzXPpB30VgYLGWtnfXCZBOlsBqv+8go6E4hVxzPHfuir6eUVkCbkv0M08oZTRda1m US77c4VgOd14sviQ1zrRcSAG5qdxElBW0n0+GguRVJbwoinlgqP18W+nSSABHYtB1TbnC+ EEkagxNiC/ip6rkyfpw6FUXAKQ8F+gs=; 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, 13 Aug 2013 18:01:39 +0100 Message-ID: <520A6677.5010902@isode.com> Date: Tue, 13 Aug 2013 18:01:43 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 To: =?ISO-8859-1?Q?Jan_Kundr=E1t?= References: <5208CD61.3070100@isode.com> <7bad458f-e05d-4df1-bbed-47190b8dbd16@flaska.net> In-Reply-To: <7bad458f-e05d-4df1-bbed-47190b8dbd16@flaska.net> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: quoted-printable Cc: imapext@ietf.org Subject: Re: [imapext] CONDSTORE interaction with SORT/THREAD 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, 13 Aug 2013 17:01:46 -0000 On 12/08/2013 14:32, Jan Kundr=E1t wrote: > On Monday, 12 August 2013 13:56:17 CEST, Alexey Melnikov wrote: >> 1). Use ESEARCH response (RFC 4731) to return MODSEQ for all matching=20 >> messages and also extend it to return sorted results. (This can be=20 >> potentially be used for SEARCH with MODSEQ search criterion as well).=20 >> For example: >> >> * ESEARCH (TAG "A001") SORTED 3,4,1,2 MODSEQ 175 > > I've just re-read the relevant bits of RFC 4551 again. I have to admit=20 > I do not understand the point of including the highest MODSEQ of the=20 > matching messages under the MODSEQ key -- what is the use case for=20 > that? Sure, it's in the RFC so we cannot change it now, but I'd like=20 > to understand the motivation behind this. This can be used to do partial mailbox resynchronization using=20 SEARCH/SORT. So it is like HIGHESTMODSEQ, just for the matching messages. >> Here SORTED is similar to ALL, but it preserves the SORT order of=20 >> matching messages. >> RFC 4731 already defines MODSEQ return item. > > Unless I'm missing something, the example response invents a=20 > non-existant "SORTED" ESEARCH return value. RFC 5267 (CONTEXT=3D...)=20 > already defines the ESORT extension and the ESORT command and how it=20 > uses the ESEARCH response (some servers were broken and used to return=20 > an ESORT response, btw). The result is passed as if it was triggered=20 > via the ESEARCH command, only in a sorted form, so the correct return=20 > data are, IMHO: > > * ESEARCH (TAG "A001") ALL 3,4,1,2 MODSEQ 175 Ok, I forgot about this :-). > I'm also confused because the command asked for MODSEQ >=3D 500, but the= =20 > response claims that the highest MODSEQ of any matching messages is 175. Yeah, I didn't pay attention to what I was typing. Assume it was=20 something like 1175. > >> 2). Extend SORT response in the same way CONDSTORE extended SEARCH=20 >> response: >> >> * SORT 5 3 4 1 2 (MODSEQ 175) > > That would require a modification of the ABNF and as such it cannot be=20 > introduced retroacitvely, right? Yes, this would require an ABNF change. We can do that, as long as the=20 new syntax is enabled when a compliant client signals a server by using=20 an extension element. >> 3). Return 2 response: an ESEARCH with MODSEQ and a SORT: >> >> * SORT 5 3 4 1 2 >> * ESEARCH (TAG "A001") MODSEQ 175 > > I realize this is about SORT, not SEARCH, but RFC 4466, section 2.6.1=20 > contains a SHOULD saying that there should only be a SEARCH *or* an=20 > ESEARCH response, not both. I don't think the prohibition intended to apply in this case. One=20 advantage of #3 is that it shouldn't break older clients, as long as=20 they ignore unrecognized response (which they should). >> I personally have a slight preference for choices #3/#1, as I don't=20 >> want to prolifirate new variants of responses which are not ESEARCH=20 >> based. > > Indeed, and for the reasons stated above, I prefer 1) after it's fixed=20 > to use ALL instead of SORTED. Right. Are you Ok with #2 after seeing Timo's response? >> 1). Use ESEARCH response (RFC 4731) to return MODSEQ for all matching=20 >> messages and also extend it to return threaded results. For example: >> >> * ESEARCH (TAG "A002") THREAD ((2)(3 6 (4 23)(44 7 96))) MODSEQ=20 >> 909240921 > > I would love to have the THREAD return option for ESEARCH; in fact,=20 > I've tried to introduce it in draft-kundrat-incthread [1]. It will=20 > help Trojita understand the matching between commands and responses=20 > and therefore enable better pipelining. Ok. I think your suggested syntax need some tweaks to comply with RFC=20 4466, but otherwise this looks sensible. I will have a more detailed=20 look later. > > With kind regards, > Jan > > [1] http://tools.ietf.org/html/draft-kundrat-incthread-01#section-2.3.1 From tss@iki.fi Tue Aug 13 12:14: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 6EE2021F9CC2 for ; Tue, 13 Aug 2013 12:14:20 -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 N6FyT8UBNfgg for ; Tue, 13 Aug 2013 12:14:14 -0700 (PDT) Received: from dovecot.org (dovecot.org [193.210.130.67]) by ietfa.amsl.com (Postfix) with ESMTP id 5E83521F9C2E for ; Tue, 13 Aug 2013 12:14:14 -0700 (PDT) Received: from [10.217.1.101] (vfw03.dovecot.fi [88.194.145.100]) by dovecot.org (Postfix) with ESMTP id 6BF721AE879A; Tue, 13 Aug 2013 22:14:09 +0300 (EEST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Timo Sirainen In-Reply-To: <520A658D.10409@isode.com> Date: Tue, 13 Aug 2013 22:14:03 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5208CD61.3070100@isode.com> <520A658D.10409@isode.com> To: Alexey Melnikov X-Mailer: Apple Mail (2.1508) Cc: "imapext@ietf.org" Subject: Re: [imapext] CONDSTORE interaction with SORT/THREAD 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, 13 Aug 2013 19:14:20 -0000 On 13.8.2013, at 19.57, Alexey Melnikov = wrote: >>> 1). Use ESEARCH response (RFC 4731) to return MODSEQ for all = matching messages and also extend it to return sorted results. (This can = be potentially be used for SEARCH with MODSEQ search criterion as well). = For example: >>>=20 >>> * ESEARCH (TAG "A001") SORTED 3,4,1,2 MODSEQ 175 >> One possibility would be to return #1, but only if some other new = parameter is used. That parameter could then also be used without = MODSEQ. It also wouldn't break with the existing Dovecot installations. > Right. For example RESMODSEQ (it has the same semantics as MODSEQ = SEARCH/SORT item, but causes ESEARCH response to be returned). I was thinking ESORT compatibility, but then of course ESORT would have = to be implemented also by the server. But if we're talking about using = ESEARCH anyway, it should be a minor job for servers to add support for = ESORT. This actually already works: a SORT RETURN (ALL) (DATE) UTF-8 MODSEQ 1234 * ESEARCH (TAG "a") ALL 5,3,2,1 MODSEQ 1236 >>> Similarly, for THREAD: >>>=20 >>> 1). Use ESEARCH response (RFC 4731) to return MODSEQ for all = matching messages and also extend it to return threaded results. For = example: >>>=20 >>> * ESEARCH (TAG "A002") THREAD ((2)(3 6 (4 23)(44 7 96))) MODSEQ = 909240921 >>>=20 >>> Here again, I prefer choices #1/#3. >> With THREAD Dovecot doesn't return MODSEQ in any way. > Ok. Which option you prefer for THREAD+CONDSTORE? Something similar to the ESORT example I think (so #1 reply with some = parameter to switch on ESEARCH reply mode). From alexey.melnikov@isode.com Wed Aug 21 03:49:23 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 1C21911E81FA for ; Wed, 21 Aug 2013 03:49:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.399 X-Spam-Level: X-Spam-Status: No, score=-102.399 tagged_above=-999 required=5 tests=[AWL=-0.100, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, 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 YQ3GNa5lnL28 for ; Wed, 21 Aug 2013 03:49:22 -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 2F05711E81F4 for ; Wed, 21 Aug 2013 03:49:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1377082161; d=isode.com; s=selector; i=@isode.com; bh=GSLHQseqrKcRg0nrY+7QmUlsxjAm1bUeSDdPBKsi6vM=; 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=fD/sPw84A0xbOn2CcpFR98JK/GvZWYt1e2Xa8K5Xj7uDxWbfVo/DaDOcBU9P5qYKq9PGEd Xfma+Oe6YN2eWUvmB7H3PCyvZFAjwkJGudMEKax3nuDYB79XthxAMVWG0a7xwIgHXrzTri KmWDu5VV5M+TpvIIU3ZHYcB6AlZPOEo=; Received: from [172.16.1.29] (shiny.isode.com [62.3.217.250]) by waldorf.isode.com (submission channel) via TCP with ESMTPA id ; Wed, 21 Aug 2013 11:49:21 +0100 Message-ID: <52149B50.5050304@isode.com> Date: Wed, 21 Aug 2013 11:49:52 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 To: =?ISO-8859-1?Q?Jan_Kundr=E1t?= MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "imapext@ietf.org" Subject: [imapext] ABNF comments on draft-kundrat-incthread-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: Wed, 21 Aug 2013 10:49:23 -0000 Hi Jan, I see in the ABNF section: ret-data-thread = "THREAD" [SP 1*thread-list] ;; from [RFC5256] ret-data-incthread = "INCTHREAD" SP uid SP thread-list ;; from [RFC3501] ;; from [RFC5256] search-return-data =/ ret-data-thread / ret-data-incthread ;; from [RFC4466] RFC 4466 requires that search-return-data either contains a simple type parameter (atom/number/set) or a complex piece of data enclosed in (). So you are missing (). I think your ABNF (and examples) should be updated: ret-data-thread = "THREAD" [SP "(" 1*thread-list ")" ] ;; from [RFC5256] ret-data-incthread = "INCTHREAD" SP "(" uid SP thread-list ")" ;; from [RFC3501] ;; from [RFC5256] Best Regards, Alexey From alexey.melnikov@isode.com Wed Aug 21 07:04: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 CF55C11E80FB for ; Wed, 21 Aug 2013 07:04:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.524 X-Spam-Level: X-Spam-Status: No, score=-102.524 tagged_above=-999 required=5 tests=[AWL=0.075, 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 JD9F2z7u-TGX for ; Wed, 21 Aug 2013 07:04:02 -0700 (PDT) Received: from statler.isode.com (statler.isode.com [62.3.217.254]) by ietfa.amsl.com (Postfix) with ESMTP id DE42411E839D for ; Wed, 21 Aug 2013 07:04:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1377093840; d=isode.com; s=selector; i=@isode.com; bh=Homp+umgTmA5ALeL1Ew03xUppp1+uvA/kO0xNjqFtIw=; 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=CgD8QlLmXQxJJhO7kD+29yuB2n3Dz0nLDKhgFRJ8rQP6nSzYHd6OlpfiEnpJ98PIUcCXQz YyPr+925keH/UY8W3auPXmdQIBvn1wlF+/16Si9RMXm3aNj9e/DpmmxGvEaGVgFNXHTstX 4yEIa1aLBJq4ccD64QKgr6q1YAkJIVQ=; Received: from [172.16.1.29] (shiny.isode.com [62.3.217.250]) by statler.isode.com (submission channel) via TCP with ESMTPA id ; Wed, 21 Aug 2013 15:04:00 +0100 Message-ID: <5214C8ED.4070602@isode.com> Date: Wed, 21 Aug 2013 15:04:29 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 To: Timo Sirainen References: <5208CD61.3070100@isode.com> <520A658D.10409@isode.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] CONDSTORE interaction with SORT/THREAD 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, 21 Aug 2013 14:04:07 -0000 On 13/08/2013 20:14, Timo Sirainen wrote: > On 13.8.2013, at 19.57, Alexey Melnikov wrote: >>>> 1). Use ESEARCH response (RFC 4731) to return MODSEQ for all matching messages and also extend it to return sorted results. (This can be potentially be used for SEARCH with MODSEQ search criterion as well). For example: >>>> >>>> * ESEARCH (TAG "A001") SORTED 3,4,1,2 MODSEQ 175 >>> One possibility would be to return #1, but only if some other new parameter is used. That parameter could then also be used without MODSEQ. It also wouldn't break with the existing Dovecot installations. >> Right. For example RESMODSEQ (it has the same semantics as MODSEQ SEARCH/SORT item, but causes ESEARCH response to be returned). > I was thinking ESORT compatibility, but then of course ESORT would have to be implemented also by the server. But if we're talking about using ESEARCH anyway, it should be a minor job for servers to add support for ESORT. This actually already works: > > a SORT RETURN (ALL) (DATE) UTF-8 MODSEQ 1234 > * ESEARCH (TAG "a") ALL 5,3,2,1 MODSEQ 1236 Ok. I've added this example to the draft. >>>> Similarly, for THREAD: >>>> >>>> 1). Use ESEARCH response (RFC 4731) to return MODSEQ for all matching messages and also extend it to return threaded results. For example: >>>> >>>> * ESEARCH (TAG "A002") THREAD ((2)(3 6 (4 23)(44 7 96))) MODSEQ 909240921 >>>> >>>> Here again, I prefer choices #1/#3. >>> With THREAD Dovecot doesn't return MODSEQ in any way. >> Ok. Which option you prefer for THREAD+CONDSTORE? > Something similar to the ESORT example I think (so #1 reply with some parameter to switch on ESEARCH reply mode). For now I added sentence that THREAD+CONDSTORE don't return MODSEQ for matching messages, as at least 2 server implementations didn't implement this (yours and mine). If people object, I can change that. From alexey.melnikov@isode.com Wed Aug 21 07:06:18 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 795C811E839B for ; Wed, 21 Aug 2013 07:06:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.389 X-Spam-Level: X-Spam-Status: No, score=-102.389 tagged_above=-999 required=5 tests=[AWL=-0.090, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, 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 B3h8iQC3kOMv for ; Wed, 21 Aug 2013 07:06:12 -0700 (PDT) Received: from statler.isode.com (statler.isode.com [62.3.217.254]) by ietfa.amsl.com (Postfix) with ESMTP id 5AB1D11E80FB for ; Wed, 21 Aug 2013 07:06:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1377093971; d=isode.com; s=selector; i=@isode.com; bh=3qcBWYkTL7K1ylqk+ljIA1lVqLqZayQ85dZzpiz9sug=; 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=Zs1L1+hkQmjlTmIfLSlmJSB+Qk3nYFgqaDhvYzXXzp8jKzRRhoTDcv+a3Z9KVq+sQKgNRH YeZjkTU/t+E8kilPTGk9AwQo3iGQBMqPaZLWPjFb9E3+wX7bM+JanQhxxaRQF5cH1Ut9Ri vdYJ4i4cOrhhO14LF9TUZE4hNK5Wn9w=; Received: from [172.16.1.29] (shiny.isode.com [62.3.217.250]) by statler.isode.com (submission channel) via TCP with ESMTPA id ; Wed, 21 Aug 2013 15:06:11 +0100 Message-ID: <5214C972.3090801@isode.com> Date: Wed, 21 Aug 2013 15:06:42 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 To: =?ISO-8859-1?Q?Jan_Kundr=E1t?= References: <5208CD61.3070100@isode.com> <7bad458f-e05d-4df1-bbed-47190b8dbd16@flaska.net> In-Reply-To: <7bad458f-e05d-4df1-bbed-47190b8dbd16@flaska.net> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: quoted-printable Cc: imapext@ietf.org Subject: Re: [imapext] CONDSTORE interaction with SORT/THREAD 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, 21 Aug 2013 14:06:18 -0000 On 12/08/2013 14:32, Jan Kundr=E1t wrote: > On Monday, 12 August 2013 13:56:17 CEST, Alexey Melnikov wrote: >> 1). Use ESEARCH response (RFC 4731) to return MODSEQ for all matching=20 >> messages and also extend it to return threaded results. For example: >> >> * ESEARCH (TAG "A002") THREAD ((2)(3 6 (4 23)(44 7 96))) MODSEQ=20 >> 909240921 > > I would love to have the THREAD return option for ESEARCH; in fact,=20 > I've tried to introduce it in draft-kundrat-incthread [1]. It will=20 > help Trojita understand the matching between commands and responses=20 > and therefore enable better pipelining. I tend to agree with Timo that this needs a new capability. So what you=20 are doing in draft-kundrat-incthread (once you fix ABNF as per my other=20 comments) is the best way forward. From internet-drafts@ietf.org Wed Aug 21 07:13: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 436E411E83A9; Wed, 21 Aug 2013 07:13:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[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 NB+v3Rc5KgUm; Wed, 21 Aug 2013 07:13:58 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D1F1011E821C; Wed, 21 Aug 2013 07:13:58 -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.70.p1 Message-ID: <20130821141358.16183.85403.idtracker@ietfa.amsl.com> Date: Wed, 21 Aug 2013 07:13:58 -0700 Cc: imapext@ietf.org Subject: [imapext] I-D Action: draft-ietf-qresync-rfc4551bis-03.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, 21 Aug 2013 14:13:59 -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-03.txt Pages : 26 Date : 2013-08-21 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-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-qresync-rfc4551bis-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From alexey.melnikov@isode.com Wed Aug 21 07:22:04 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 DC92211E83C9 for ; Wed, 21 Aug 2013 07:22:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.524 X-Spam-Level: X-Spam-Status: No, score=-102.524 tagged_above=-999 required=5 tests=[AWL=0.075, 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 UlirTqWgsvtu for ; Wed, 21 Aug 2013 07:22:04 -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 0738011E8105 for ; Wed, 21 Aug 2013 07:22:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1377094922; d=isode.com; s=selector; i=@isode.com; bh=GyeR8kkBpAac/V8EQNWrlHeqfPVhwNEoxBUbwFV+2xA=; 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=Lsda7ltcNw5h/V83g36ps9DFsnJYH3NhvYizfVzFzwOfTsVIt0oqZ6DWNLXiaouNr05cgm mMyAzpQQRvf0svaYsPvDYZms0X84F6Wu6QE9x97FcnYHn/6rEXa4LVf7mWqP29sZbwkpwR 4cOz83meaxze4uNofkdhvZUDw6vlp7c=; Received: from [172.16.1.29] (shiny.isode.com [62.3.217.250]) by waldorf.isode.com (submission channel) via TCP with ESMTPA id ; Wed, 21 Aug 2013 15:22:02 +0100 Message-ID: <5214CD29.2050108@isode.com> Date: Wed, 21 Aug 2013 15:22:33 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 To: imapext@ietf.org References: <20130821141358.16183.85403.idtracker@ietfa.amsl.com> In-Reply-To: <20130821141358.16183.85403.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [imapext] I-D Action: draft-ietf-qresync-rfc4551bis-03.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, 21 Aug 2013 14:22:05 -0000 On 21/08/2013 15:13, internet-drafts@ietf.org 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-03.txt > Pages : 26 > Date : 2013-08-21 This version clarified interaction between CONDSTORE and THREAD, SORT, ESORT and ESEARCH. From jkt@flaska.net Tue Aug 27 02:25: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 AC72D21F9A2A for ; Tue, 27 Aug 2013 02:25:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.904 X-Spam-Level: X-Spam-Status: No, score=-0.904 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, MIME_QP_LONG_LINE=1.396, 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 r1M6KLDJM1kD for ; Tue, 27 Aug 2013 02:25:00 -0700 (PDT) Received: from latimerie.flaska.net (latimerie.flaska.net [IPv6:2a02:2b88:2:1::4a7:333]) by ietfa.amsl.com (Postfix) with ESMTP id D236A21F8411 for ; Tue, 27 Aug 2013 02:24:59 -0700 (PDT) Received: by latimerie.flaska.net (Postfix, from userid 1000) id 8D3C960A34; Tue, 27 Aug 2013 11:24:57 +0200 (CEST) From: =?iso-8859-1?Q?Jan_Kundr=E1t?= To: Date: Tue, 27 Aug 2013 11:24:55 +0200 User-Agent: Trojita/v0.3.93-309-gc6294be-dirty; Qt/4.8.4; X11; Linux; MIME-Version: 1.0 Message-ID: <9560f9a4-047c-4e06-a6ac-47a170b1467d@flaska.net> In-Reply-To: <52149B50.5050304@isode.com> References: <52149B50.5050304@isode.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Subject: Re: [imapext] ABNF comments on draft-kundrat-incthread-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, 27 Aug 2013 09:25:01 -0000 On Wednesday, 21 August 2013 12:49:52 CEST, Alexey Melnikov wrote: > RFC 4466 requires that search-return-data either contains a=20 > simple type parameter (atom/number/set) or a complex piece of=20 > data enclosed in (). So you are missing (). I think your ABNF=20 > (and examples) should be updated: Hi Alexey, thanks for catching this. I've now pushed a new version, -02, which=20 includes this fix. With kind regards, Jan http://tools.ietf.org/rfcdiff?difftype=3D--hwdiff&url2=3Ddraft-kundrat-incthr= ead-02.txt --=20 Trojit=C3=A1, a fast Qt IMAP e-mail client -- http://trojita.flaska.net/