From jkt@flaska.net Tue Dec 3 02:45:45 2013 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84EED1AE0FC for ; Tue, 3 Dec 2013 02:45:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.299 X-Spam-Level: X-Spam-Status: No, score=0.299 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, MIME_8BIT_HEADER=0.3, MIME_QP_LONG_LINE=0.001, RP_MATCHES_RCVD=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CUJj6Qm9e-t7 for ; Tue, 3 Dec 2013 02:45:43 -0800 (PST) Received: from latimerie.flaska.net (latimerie.flaska.net [IPv6:2a02:2b88:2:1::4a7:333]) by ietfa.amsl.com (Postfix) with ESMTP id A50771AE0C5 for ; Tue, 3 Dec 2013 02:45:43 -0800 (PST) Received: by latimerie.flaska.net (Postfix, from userid 1000) id 9669963184; Tue, 3 Dec 2013 11:45:38 +0100 (CET) From: =?iso-8859-1?Q?Jan_Kundr=E1t?= To: Date: Tue, 03 Dec 2013 11:45:38 +0100 User-Agent: Trojita/v0.3.96-130-gf259349; Qt/4.8.5; X11; Linux; MIME-Version: 1.0 Message-ID: In-Reply-To: <08f2fdeb-957f-4ed4-a827-bdce2094275f@flaska.net> References: <20131008141122.25649.73956.idtracker@ietfa.amsl.com> <368e22b4-930e-4882-bca4-8b23bc3d4b06@flaska.net> <5293A4FF.6030406@isode.com> <08f2fdeb-957f-4ed4-a827-bdce2094275f@flaska.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Subject: Re: [imapext] I-D Action: draft-ietf-qresync-rfc5162bis-03.txt X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Dec 2013 10:45:45 -0000 So, with the WG last call deadline approaching, I would appreciate some=20 sort of feedback on the points I raised. The so far unaddressed issues are: - Some corner cases are not well-defined when it comes to VANISHED=20 reporting of messages which were just made available to the client via=20 EXISTS. - Relation with METADATA and ANNOTATE-EXPERIMENT-1. What I would like to=20 see here is explicit confirmation that any change in METADATA increments=20 the HIGHESTMODSEQ and that the data tracked by ANNOTATE-EXPERIMENT-1 are in=20= fact "metadata" to be included in the MODSEQ tracking. With kind regards, Jan --=20 Trojit=C3=A1, a fast Qt IMAP e-mail client -- http://trojita.flaska.net/ From tss@iki.fi Tue Dec 3 04:22:13 2013 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 665681ADEB6 for ; Tue, 3 Dec 2013 04:22:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.601 X-Spam-Level: X-Spam-Status: No, score=-6.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fq9qOpdvNB6d for ; Tue, 3 Dec 2013 04:22:10 -0800 (PST) Received: from dovecot.org (dovecot.org [193.210.130.67]) by ietfa.amsl.com (Postfix) with ESMTP id 27B061ADEA6 for ; Tue, 3 Dec 2013 04:22:10 -0800 (PST) Received: from [192.168.10.100] (cs181255018.pp.htv.fi [82.181.255.18]) by dovecot.org (Postfix) with ESMTP id 8068F1AE87F8; Tue, 3 Dec 2013 14:22:06 +0200 (EET) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) From: Timo Sirainen In-Reply-To: <08f2fdeb-957f-4ed4-a827-bdce2094275f@flaska.net> Date: Tue, 3 Dec 2013 14:22:05 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <031754AC-66CB-417D-B620-B744A26F9CA5@iki.fi> References: <20131008141122.25649.73956.idtracker@ietfa.amsl.com> <368e22b4-930e-4882-bca4-8b23bc3d4b06@flaska.net> <5293A4FF.6030406@isode.com> <08f2fdeb-957f-4ed4-a827-bdce2094275f@flaska.net> To: =?windows-1252?Q?Jan_Kundr=E1t?= X-Mailer: Apple Mail (2.1822) Cc: imapext@ietf.org Subject: Re: [imapext] I-D Action: draft-ietf-qresync-rfc5162bis-03.txt X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Dec 2013 12:22:13 -0000 On 26.11.2013, at 0.54, Jan Kundr=E1t wrote: >> However, I don't see a problem with this. Can you elaborate why = sending VANISHED for UIDs the client hasn't seen yet is a problem? >=20 > Safety. QRESYNC is a complex extension and there's quite a potential = for both servers and clients to introduce subtle bugs which only = manifest themselves in uncommon situations. When my client sees = something which doesn't make any sense, it's much better to reject this = explicitly and point out that either the server or the client are broken = than to lose data. >=20 > One example: >=20 > (two messages exists, UIDs 1 and 2) > S: * 4 EXISTS > S: * VANISHED 5 >=20 > What UIDs are present at this point? Doesn=92t matter, you only knew about UIDs 1 and 2, which are present. > Are there two, three or four messages in there, i.e. did VANISHED = actually remoev anything? Assuming we=92ll now require that there are no unnecessary VANISHED = replies, there are 3 messages. You=92ll have to FETCH their UIDs (and = other data) in any case, so you simply remove the last message. This is = what imaptest does: = http://hg.dovecot.org/imaptest/file/7c63941f6c03/src/client.c#l124 > This is why I proposed replacing EXISTS with something like the = UID-based ARRIVED [1]. This was rejected in an attempt at reducing the = amount of changes needed in the existing software, which makes sense. = However, I believe that these corner cases have to described in the = spec. NOTIFY would allow sending FETCH responses with UIDs when new messages = arrive. From jkt@flaska.net Tue Dec 3 08:27:19 2013 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8441C1A1F65 for ; Tue, 3 Dec 2013 08:27:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.601 X-Spam-Level: X-Spam-Status: No, score=-1.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Waay1TScunva for ; Tue, 3 Dec 2013 08:27:17 -0800 (PST) Received: from latimerie.flaska.net (latimerie.flaska.net [IPv6:2a02:2b88:2:1::4a7:333]) by ietfa.amsl.com (Postfix) with ESMTP id 82A3A1A1F62 for ; Tue, 3 Dec 2013 08:27:17 -0800 (PST) Received: by latimerie.flaska.net (Postfix, from userid 1000) id 4F21363184; Tue, 3 Dec 2013 17:27:11 +0100 (CET) From: =?iso-8859-1?Q?Jan_Kundr=E1t?= To: Date: Tue, 03 Dec 2013 17:27:11 +0100 User-Agent: Trojita/v0.3.96-130-gf259349; Qt/4.8.5; X11; Linux; MIME-Version: 1.0 Message-ID: <0021573d-62e4-4c19-aeaf-bb9c43dd931e@flaska.net> In-Reply-To: <031754AC-66CB-417D-B620-B744A26F9CA5@iki.fi> References: <20131008141122.25649.73956.idtracker@ietfa.amsl.com> <368e22b4-930e-4882-bca4-8b23bc3d4b06@flaska.net> <5293A4FF.6030406@isode.com> <08f2fdeb-957f-4ed4-a827-bdce2094275f@flaska.net> <031754AC-66CB-417D-B620-B744A26F9CA5@iki.fi> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Subject: Re: [imapext] I-D Action: draft-ietf-qresync-rfc5162bis-03.txt X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Dec 2013 16:27:19 -0000 On Tuesday, 3 December 2013 13:22:05 CEST, Timo Sirainen wrote: > Assuming we=E2=80=99ll now require that there are no unnecessary=20 > VANISHED replies, there are 3 messages. You=E2=80=99ll have to FETCH=20 > their UIDs (and other data) in any case, so you simply remove=20 > the last message. This is what imaptest does:=20 > http://hg.dovecot.org/imaptest/file/7c63941f6c03/src/client.c#l124 And that's the point I'm making here. I want to make sure that each UID I=20 see in the VANISHED list corresponds to an actual removal. Look at the=20 current wording: Note that a VANISHED response [...] MUST only contain UIDs for messages expunged since the last VANISHED/EXPUNGE response sent for the currently opened mailbox or since the mailbox was opened. That is, servers MUST NOT send UIDs for previously expunged messages, unless explicitly requested to do so by the UID FETCH (VANISHED) command. This wording does not forbid the following behavior: - 2 messages exist, UIDs 1 and 2 S: * 2 EXISTS - UIDs now 1, 2, 3, 4, but client doesn't know that yet - one message arrives, UIDs are now (1,2,3,4,5), the server does not send=20 out EXISTS for some reason before it is removed in a concurrent session S: * VANISHED 5 Yes, the server would be very dumb to do this. However, I prefer to not=20 make any room for an incorrect interpretation here. See my other mail for=20 the proposed wording. Cheers, Jan --=20 Trojit=C3=A1, a fast Qt IMAP e-mail client -- http://trojita.flaska.net/ From adrien@qbik.com Tue Dec 3 11:58:42 2013 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7CD71AD68D for ; Tue, 3 Dec 2013 11:58:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.602 X-Spam-Level: X-Spam-Status: No, score=-1.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id usJlmNj_hCVf for ; Tue, 3 Dec 2013 11:58:41 -0800 (PST) Received: from smtp.qbik.com (smtp.qbik.com [210.55.214.35]) by ietfa.amsl.com (Postfix) with ESMTP id 9468C1AC404 for ; Tue, 3 Dec 2013 11:58:40 -0800 (PST) Received: From [192.168.0.23] (unverified [192.168.0.23]) by SMTP Server [192.168.0.1] (WinGate SMTP Receiver v8.0.5 (Build 4632)) with SMTP id <0019906074@smtp.qbik.com>; Wed, 04 Dec 2013 08:58:42 +1300 From: "Adrien de Croy" To: =?utf-8?q?Jan=20Kundr=c3=a1t?= , "imapext@ietf.org" Date: Tue, 03 Dec 2013 19:58:42 +0000 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; format=flowed; charset=utf-8 In-Reply-To: <0021573d-62e4-4c19-aeaf-bb9c43dd931e@flaska.net> Message-Id: Mime-Version: 1.0 User-Agent: eM_Client/5.0.19406.0 Subject: Re: [imapext] I-D Action: draft-ietf-qresync-rfc5162bis-03.txt X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Adrien de Croy List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Dec 2013 19:58:42 -0000 does this mean it would place the burden on the server to track what=20 UIDs the client shoudl know about just so a client doesn't have to=20 discard a VANISHED response for a message it had no knowledge of? Seems backwards to me. I would imagine it would be more trouble than=20 it's worth to break things on that, when you can simply ignore it - why=20 should a client care if a message it never knew about is deleted? Seems to me that by placing more onerous requirements on the server=20 (like maintaining a view of reported UIDs under all circumstances), that= =20 is more likely to lead to real in-the-world problems? Adrien ------ Original Message ------ From: "Jan Kundr=C3=A1t" To: "imapext@ietf.org" Sent: 4/12/2013 5:27:11 a.m. Subject: Re: [imapext] I-D Action: draft-ietf-qresync-rfc5162bis-03.txt >On Tuesday, 3 December 2013 13:22:05 CEST, Timo Sirainen wrote: >>Assuming we=E2=80=99ll now require that there are no unnecessary VANISHED= =20 >>replies, there are 3 messages. You=E2=80=99ll have to FETCH their UIDs= (and=20 >>other data) in any case, so you simply remove the last message. This=20 >>is what imaptest does:=20 >>http://hg.dovecot.org/imaptest/file/7c63941f6c03/src/client.c#l124 > >And that's the point I'm making here. I want to make sure that each UID= =20 >I see in the VANISHED list corresponds to an actual removal. Look at=20 >the current wording: > > Note that a VANISHED response [...] MUST only contain UIDs for > messages expunged since the last VANISHED/EXPUNGE response sent for > the currently opened mailbox or since the mailbox was opened. That > is, servers MUST NOT send UIDs for previously expunged messages, > unless explicitly requested to do so by the UID FETCH (VANISHED) > command. > >This wording does not forbid the following behavior: > >- 2 messages exist, UIDs 1 and 2 >S: * 2 EXISTS >- UIDs now 1, 2, 3, 4, but client doesn't know that yet >- one message arrives, UIDs are now (1,2,3,4,5), the server does not=20 >send out EXISTS for some reason before it is removed in a concurrent=20 >session >S: * VANISHED 5 > >Yes, the server would be very dumb to do this. However, I prefer to not= =20 >make any room for an incorrect interpretation here. See my other mail=20 >for the proposed wording. > >Cheers, >Jan > >-- Trojit=C3=A1, a fast Qt IMAP e-mail client -- http://trojita.flaska.net= / >_______________________________________________ >imapext mailing list >imapext@ietf.org >https://www.ietf.org/mailman/listinfo/imapext From tss@iki.fi Tue Dec 3 12:08:15 2013 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5A051AE15B for ; Tue, 3 Dec 2013 12:08:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8ix4O6MYax0m for ; Tue, 3 Dec 2013 12:08:12 -0800 (PST) Received: from dovecot.org (dovecot.org [193.210.130.67]) by ietfa.amsl.com (Postfix) with ESMTP id 055311AC3DA for ; Tue, 3 Dec 2013 12:08:12 -0800 (PST) Received: from [192.168.10.100] (cs181255018.pp.htv.fi [82.181.255.18]) by dovecot.org (Postfix) with ESMTP id 10ACC1AE87F0; Tue, 3 Dec 2013 22:08:07 +0200 (EET) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) From: Timo Sirainen In-Reply-To: Date: Tue, 3 Dec 2013 22:08:06 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <420444CE-45E0-413C-ADB7-1414EEDF6A42@iki.fi> References: To: Adrien de Croy X-Mailer: Apple Mail (2.1822) Cc: =?windows-1252?Q?Jan_Kundr=E1t?= , "imapext@ietf.org" Subject: Re: [imapext] I-D Action: draft-ietf-qresync-rfc5162bis-03.txt X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Dec 2013 20:08:15 -0000 This requirement doesn=92t place any extra restrictions that don=92t = already exist with regular EXPUNGE. If server has sent =93* 5 EXISTS=94 = to client last, the server would never send =93* 6 EXPUNGE=94 to client. = In a similar way it wouldn=92t send the equivalent VANISHED with 6=92s = UID. This situation of course happens only if a message arrives and is = immediately expunged without never having had a chance to be sent to = client via EXISTS. So Jan isn=92t talking about keeping track of which FETCH UID replies = have been sent to client, that would be extra trouble. I think Jan=92s = wording here is confusing: A VANISHED response without the EARLIER tag MUST only refer to a UID which was visible to the session at the time the response is sent. In particular, this means that VANISHED response MUST NOT refer to a message whose removal was already communicated to the client, or to a message whose UID has not been present in the mailbox yet. This is required to prevent a possible race condition where new arrivals for which the UID is not yet known by the client are expunged. It shouldn=92t be talking about UIDs=92 visibility at all. It should be = talking about messages=92 visibility (via EXISTS). Whether the client = knows the new messages=92 UIDs isn=92t relevant. On 3.12.2013, at 21.58, Adrien de Croy wrote: >=20 > does this mean it would place the burden on the server to track what = UIDs the client shoudl know about just so a client doesn't have to = discard a VANISHED response for a message it had no knowledge of? >=20 > Seems backwards to me. I would imagine it would be more trouble than = it's worth to break things on that, when you can simply ignore it - why = should a client care if a message it never knew about is deleted? >=20 > Seems to me that by placing more onerous requirements on the server = (like maintaining a view of reported UIDs under all circumstances), that = is more likely to lead to real in-the-world problems? >=20 > Adrien >=20 >=20 > ------ Original Message ------ > From: "Jan Kundr=E1t" > To: "imapext@ietf.org" > Sent: 4/12/2013 5:27:11 a.m. > Subject: Re: [imapext] I-D Action: = draft-ietf-qresync-rfc5162bis-03.txt >> On Tuesday, 3 December 2013 13:22:05 CEST, Timo Sirainen wrote: >>> Assuming we=92ll now require that there are no unnecessary VANISHED = replies, there are 3 messages. You=92ll have to FETCH their UIDs (and = other data) in any case, so you simply remove the last message. This is = what imaptest does: = http://hg.dovecot.org/imaptest/file/7c63941f6c03/src/client.c#l124 >>=20 >> And that's the point I'm making here. I want to make sure that each = UID I see in the VANISHED list corresponds to an actual removal. Look at = the current wording: >>=20 >> Note that a VANISHED response [...] MUST only contain UIDs for >> messages expunged since the last VANISHED/EXPUNGE response sent for >> the currently opened mailbox or since the mailbox was opened. That >> is, servers MUST NOT send UIDs for previously expunged messages, >> unless explicitly requested to do so by the UID FETCH (VANISHED) >> command. >>=20 >> This wording does not forbid the following behavior: >>=20 >> - 2 messages exist, UIDs 1 and 2 >> S: * 2 EXISTS >> - UIDs now 1, 2, 3, 4, but client doesn't know that yet >> - one message arrives, UIDs are now (1,2,3,4,5), the server does not = send out EXISTS for some reason before it is removed in a concurrent = session >> S: * VANISHED 5 >>=20 >> Yes, the server would be very dumb to do this. However, I prefer to = not make any room for an incorrect interpretation here. See my other = mail for the proposed wording. >>=20 >> Cheers, >> Jan >>=20 >> -- Trojit=E1, a fast Qt IMAP e-mail client -- = http://trojita.flaska.net/ >> _______________________________________________ >> imapext mailing list >> imapext@ietf.org >> https://www.ietf.org/mailman/listinfo/imapext >=20 > _______________________________________________ > imapext mailing list > imapext@ietf.org > https://www.ietf.org/mailman/listinfo/imapext From dave@cridland.net Tue Dec 3 13:16:03 2013 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 862DD1AE0EF for ; Tue, 3 Dec 2013 13:16:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.078 X-Spam-Level: X-Spam-Status: No, score=-1.078 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qXjTH3Wm_i-4 for ; Tue, 3 Dec 2013 13:16:00 -0800 (PST) Received: from mail-oa0-x22c.google.com (mail-oa0-x22c.google.com [IPv6:2607:f8b0:4003:c02::22c]) by ietfa.amsl.com (Postfix) with ESMTP id DCF371ADF5F for ; Tue, 3 Dec 2013 13:15:59 -0800 (PST) Received: by mail-oa0-f44.google.com with SMTP id m1so15723994oag.31 for ; Tue, 03 Dec 2013 13:15:57 -0800 (PST) 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 :cc:content-type; bh=siVAxXJbvx/QQ0I4W0OspKR3IHILO6ugnfwn+QM454I=; b=ESp9oQUi00KMyfTF21upjlE65oJBxDI1MtUV/Gj0fHtIGpvA+iQv5PQlvShLyxEz5c F/wtY/1TDT88nKgc9IVLHot34HSoqxbLSwsZvsSWUaGJhigRvP1Yk2pULKYEhRkdlgmR /NoSNwJt77bSXx/7VrLF+7h/9SYtvHkpR6VQw= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=siVAxXJbvx/QQ0I4W0OspKR3IHILO6ugnfwn+QM454I=; b=crLXJXxQ1DCZns+KDn1S0oPZsFsWpe/O+5hRUBtbNWRVnaOk0QHdIl8ysOL1o/QvfD iD96TbdKeSEnfZkpXm54X90egyCBwiqIklJAJMPse16O07ByQKby4BpFaOHW+msDsauQ 9CGsAx/vzjdfe3MoqKoLMVtZpd+CrzZoAzUNNSUR+b979zEjXuYf7sdLFNs1pbYIwlYv EDEe6gtcDLT8jaM7jLGjxSvEwUIdFbE+XkW031Boc5KFdDyfeDidfM1zAih9ZdPvhR9A 4VCGlNL1xLxmeOpIv1vV9ctqaUBUPMIkOquJAQ8YCFUVI5ABxk1OlhqNmToVcTt18mO4 qosg== X-Gm-Message-State: ALoCoQltDf97tFMArsI5xO/+6OK2yDzoSdaHf4Q8w/0dHodXzL9rHC8cVRzsGEgldKmVE0QJdEzZ MIME-Version: 1.0 X-Received: by 10.182.227.136 with SMTP id sa8mr11471567obc.39.1386105356884; Tue, 03 Dec 2013 13:15:56 -0800 (PST) Received: by 10.60.121.97 with HTTP; Tue, 3 Dec 2013 13:15:56 -0800 (PST) In-Reply-To: <08f2fdeb-957f-4ed4-a827-bdce2094275f@flaska.net> References: <20131008141122.25649.73956.idtracker@ietfa.amsl.com> <368e22b4-930e-4882-bca4-8b23bc3d4b06@flaska.net> <5293A4FF.6030406@isode.com> <08f2fdeb-957f-4ed4-a827-bdce2094275f@flaska.net> Date: Tue, 3 Dec 2013 21:15:56 +0000 Message-ID: From: Dave Cridland To: =?ISO-8859-1?Q?Jan_Kundr=E1t?= Content-Type: multipart/alternative; boundary=001a11c303506b3b5f04eca7cdd3 Cc: "imapext@ietf.org" Subject: Re: [imapext] I-D Action: draft-ietf-qresync-rfc5162bis-03.txt X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Dec 2013 21:16:03 -0000 --001a11c303506b3b5f04eca7cdd3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Mon, Nov 25, 2013 at 10:54 PM, Jan Kundr=E1t wrote: > One example: > > (two messages exists, UIDs 1 and 2) > S: * 4 EXISTS > S: * VANISHED 5 > I think this is a terrible example, but I think the problem is real. Try this one: C: A SELECT INBOX S: [...] S: * UIDNEXT 10000 S: * EXISTS 8999 S: A OK [READ-WRITE] Done. Simple enough here. Client wants to look at the last 1k messages. I'll show an ESEARCH, though this could equally well be a FETCH. C: B UID SEARCH RETURN (ALL) 8000:* S: * ESEARCH (TAG "B") UID ALL 9000:9999 S: B OK Completed. But now: C: C NOOP S: * VANISHED 5 S: C OK Done. How many messages are now in the INBOX? Dave. --001a11c303506b3b5f04eca7cdd3 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Mon, Nov 25, 2013 at 10:54 PM, Jan Kundr=E1t <jkt@flaska= .net> wrote:
One example:

(two messages exists, UIDs 1 and 2)
S: * 4 EXISTS
S: * VANISHED 5


I think = this is a terrible example, but I think the problem is real. Try this one:<= /div>

C: A SELECT INBOX
S: [...]
S: * UIDNEXT 10000
S: * EXISTS 8999
S: A OK [READ-WRITE= ] Done.

Simple enough here. Client wants to look a= t the last 1k messages. I'll show an ESEARCH, though this could equally= well be a FETCH.

C: B UID SEARCH RETURN (ALL) 8000:*
S: * ESEA= RCH (TAG "B") UID ALL 9000:9999
S: B OK Completed.

But now:

C: C NOOP
S: * VANISHED 5
S: C OK Done.

How many m= essages are now in the INBOX?

Dave.
--001a11c303506b3b5f04eca7cdd3-- From samsungsvl@yahoo.com Tue Dec 3 14:21:30 2013 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5BF91ADF71 for ; Tue, 3 Dec 2013 14:21:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7-x8ZWOp4VXV for ; Tue, 3 Dec 2013 14:21:27 -0800 (PST) Received: from nm19-vm0.bullet.mail.bf1.yahoo.com (nm19-vm0.bullet.mail.bf1.yahoo.com [98.139.213.162]) by ietfa.amsl.com (Postfix) with SMTP id 6F3F01AE1AF for ; Tue, 3 Dec 2013 14:21:20 -0800 (PST) Received: from [98.139.212.151] by nm19.bullet.mail.bf1.yahoo.com with NNFMP; 03 Dec 2013 22:21:17 -0000 Received: from [98.139.212.217] by tm8.bullet.mail.bf1.yahoo.com with NNFMP; 03 Dec 2013 22:21:17 -0000 Received: from [127.0.0.1] by omp1026.mail.bf1.yahoo.com with NNFMP; 03 Dec 2013 22:21:17 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 591767.59214.bm@omp1026.mail.bf1.yahoo.com Received: (qmail 73096 invoked by uid 60001); 3 Dec 2013 22:21:17 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1386109277; bh=LGh7SUlLCySCKg2TjSxTum3RKKLqHqPW4jUM50Vf4MI=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=bpNIgUID8v65yzqzFY/h6X+KtG/NxQtRg4iszyKzqF+/ui66oDpJqT4jsTAJi88bgy6DQARVioZvBYUIe2q/xjIdUy/o9Nrf6tOkm1QA963vVsgEN83AZNqMDTWtCTIL5aDCGKfIn29OHtQSMbEJbv8o7l/qSQbLrLwQWczOvQo= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=b414GiwhUgkpDt4TVOaPvmXddn+i2HFkKZVWxXV5Yf5HS/5PYKbjeTt72VwggHW/6uxsNutNHyQqv8q48i2wHiim7CHHbxqcxUIrjNfQ/mF0tiVrByZnDNLCIbwc2Sg0ggY4eMuC9cd5BK3NwRemjrMFuOkQDuk24MUsyqz/ovs=; X-YMail-OSG: gDFAr8UVM1lTUJWTHDsRaNK04m8JNLYi51jiPmoH3MM3HF9 QsL6ehbiNRi8YJ.Nx3bpq0wl29T4OobKOQCi7aGebdt8sz.OoXoAhV_tPQs4 EdI.xcdic06eZyVvz4XlL0nTPgDOPcYvsk4IF9pxXa_r9Y.2KUkVpeifQcPJ AsiuPbdyz1clC.wKFDftIFk7vSSuPsBL.TzILCFTEBBBVNTE3q0zaaqImqXH QImP72bjyqFBnk_59Q9mgJTBjcgcb41eSAqSnrg7p_8wJmW_D3.e.7Ta5yUL k2nWrNo2KzSxHKy0Hcm2MT0VXBM5hjxu8W5sx4LSHLd7rx9EwO49eK7k.60f VINEm8bpJ7OcFop4sKVB6LsNVFkbo8m1brGWROPtl3JPbcH8zETcnbff_sgY dACkIyEAw7ThcjcTaGWgbeFQBCu6Tmd3zgJ3WhOIfGL5mEcd4Fa1Lkhw8MB4 beYtsEjwU_dCSZ8h9To5vV.BvVP.WDZpBCu37UCWwISFPTpIhcArjJYUEKBn h5CBjMMv7C4BQQF78nzdGVvPBtRYGHs9zKDOZxAELf4aVt6iE7g5dzxmIiYE Ld_iPcHordSR6ORELQpbWSEijp7rjYz7SYiDUaeIZ0K_gAleQYHbV0cs4tht eSoQJqA-- Received: from [63.166.115.40] by web160203.mail.bf1.yahoo.com via HTTP; Tue, 03 Dec 2013 14:21:17 PST X-Rocket-MIMEInfo: 002.001, SGkgRGF2ZS9BbGV4eSwKCkkgaGF2ZSBnb25lIHRocm91Z2ggdGhlwqBodHRwczovL2lldGYub3JnL2RvYy9kcmFmdC1pZXRmLXFyZXN5bmMtcmZjNTE2MmJpcy_CoGRyYWZ0LiBSZWdhcmRpbmcgdGhlIGlzc3VlIHJlcG9ydGVkIGVhcmxpZXIsIHNvbWUgc2VydmVyIGV4cGxpY2l0bHkgZXhwZWN0cyBFTkFCTEUgY29tbWFuZCB0byBpbmNyZW1lbnQgdGhlIEhJR0hFU1RNT0RTRVEgYW5kIHNvbWUgc2VydmVyIGF1dG9tYXRpY2FsbHkgaW5jcmVtZW50cy4gVG8gbWFrZSB0aGUgdGhpbmcgY2xlYXIgYW5kIGFsc28BMAEBAQE- X-Mailer: YahooMailWebService/0.8.167.602 References: <1386021084.78345.YahooMailNeo@web160203.mail.bf1.yahoo.com> <9576257CC412C5B483A28644@96B2F16665FF96BAE59E9B90> <1386028949.42306.YahooMailNeo@web160201.mail.bf1.yahoo.com> Message-ID: <1386109277.12951.YahooMailNeo@web160203.mail.bf1.yahoo.com> Date: Tue, 3 Dec 2013 14:21:17 -0800 (PST) From: Samsung SVL To: Dave Cridland , "Alexey.Melnikov@isode.com" In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-2111173271-216864622-1386109277=:12951" Cc: "lemonade@ietf.org" , Chris Newman , "j.sb@sta.samsung.com" , "imapext@ietf.org" Subject: Re: [imapext] [lemonade] Regarding CONDSTORE IMAP extension X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Samsung SVL List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Dec 2013 22:21:31 -0000 ---2111173271-216864622-1386109277=:12951 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Hi Dave/Alexy,=0A=0AI have gone through the=A0https://ietf.org/doc/draft-ie= tf-qresync-rfc5162bis/=A0draft. Regarding the issue reported earlier, some = server explicitly expects ENABLE command to increment the HIGHESTMODSEQ and= some server automatically increments. To make the thing clear and also to = follow the consistent behavior across various IMAP clients.=A0It would be b= etter to insist a point about enabling the CONDSTORE service in the server = by sending ENABLE CONDSTORE command.=0A=0ASo, even-though server advertises= the supported capability, its client responsibility to send ENABLE CONDSTO= RE command to enable the service. In case, if IMAP server did not support t= he ENABLE extension, then how client should enable the service can also men= tioned to make it clear for client implementation.=A0=0A=0APlease consider = and if you feel its worthy, kindly update the draft.=A0=0A=0ARegards,=0AJay= =0A=0A>________________________________=0A> From: Dave Cridland =0A>To: Samsung SVL =0A>Cc: Chris Newman ; "lemonade@ietf.org" =0A>Sent: T= uesday, 3 December 2013, 0:52=0A>Subject: Re: [lemonade] Regarding CONDSTOR= E IMAP extension=0A> =0A>=0A>=0A>Just to remind folk, the update to RFC 455= 1 - now also documenting QRESYNC as well - is currently in Working Group La= st Call, which ends on the 6th of December.=0A>=0A>=0A>https://ietf.org/doc= /draft-ietf-qresync-rfc5162bis/=0A>=0A>=0A>=0A>If you think this needs to b= e clearer in the new document, please let the document authors, and the mai= ling list at imapext@ietf.org know.=0A>=0A>=0A>=0A>On Tue, Dec 3, 2013 at 1= 2:02 AM, Samsung SVL wrote:=0A>=0A>Hi Chris,=0A>>=0A= >>=0A>>Thanks for your clarification.=0A>>=0A>>=0A>>Regards,=0A>>Jay=0A>>= =0A>>=0A>>=0A>>>________________________________=0A>>> From: Chris Newman <= chris.newman@oracle.com>=0A>>>To: Samsung SVL ; lemon= ade@ietf.org =0A>>>Sent: Monday, 2 December 2013, 18:10=0A>>>=0A>>>Subject:= Re: [lemonade] Regarding CONDSTORE IMAP extension=0A>>>=0A>>>=0A>>>=0A>>>-= -On December 2, 2013 13:51:24 -0800 Samsung SVL =0A>= >>=0A>>>wrote:=0A>>>=0A>>>> Hi All,=0A>>>>=0A>>>> Kindly clarify my below q= uery regarding "CONDSTORE" IMAP Extension.=0A>>>>=0A>>>> When IMAP server a= dvertises the "CONDSTORE" support as part of=0A>>>> CAPABILITIES, client as= sumes that server support IMAP CONSTORE=0A>>>> extension.=A0=0A>>>>=0A>>>> = As=0A per RFC 4551,=A0=A0client issues SELECT command =A0for a mailbox in t= he=0A>>>> below format and receives the response with HIGHESTMODSEQ value a= s =A0"1"=0A>>>>=0A>>>> C: A142 SELECT INBOX=0A>>>>=0A>>>> During the subseq= uent SELECT command, client receives "HIGHESTMODSEQ"=0A>>>> value always se= t to "1". Its not getting incremented with respect to the=0A>>>> changes in= the mailbox.=A0=0A>>>>=0A>>>> Some IMAP server changes the HIGHESTMODSEQ v= alue only when client issues=0A>>>> SELECT command in the below format.=0A>= >>>=0A>>>> C:A142 SELECT "INBOX" (QRESYNC ("UIDVALIDITY" "HIGHESTMODSEQ"))= =0A>>>>=0A>>>> Kindly clarify which format is right one, because most of th= e IMAP server=0A>>>> behaves differently.=A0=0A>>>=0A>>>Technically, the fo= rmer command is correct only if you've previously issued =0A>>>a condstore-= enabling command (or don't want to use condstore) and the =0A>>>latter is c= orrect only if the server advertises QRESYNC and you have issued =0A>>>"ENA= BLE QRESYNC" previously. For more details see RFC 4551 and RFC 5162.=0A>>>= =0A>>>Have you tried using:=0A>>>=0A>>>C: A142 SELECT INBOX (CONDSTORE)=0A>= >>=0A>>>That's a condstore-enabling command that servers advertising the CO= NDSTORE =0A>>>capability are required to support. Servers are free to not r= eturn =0A>>>HIGHESTMODSEQ at all until a condstore-enabling command occurs,= and then =0A>>>they MUST return either HIGHESTMODSEQ or NOMODSEQ.=0A>>>=0A= >>>Of course, if a server is returning HIGHESTMODSEQ and not updating it af= ter =0A>>>flag=0A changes, that server may have a bug, so you may have to f= allback to =0A>>>not using CONDSTORE with that server and just do a full re= sync every time. =0A>>>You might want to report that bug to the server vend= or so they have the =0A>>>opportunity to fix it in a subsequent release.=0A= >>>=0A>>>=A0=A0=A0 =A0=A0=A0 - Chris=0A>>>=0A>>>=0A>>>=0A>>>=0A>>__________= _____________________________________=0A>>lemonade mailing list=0A>>lemonad= e@ietf.org=0A>>https://www.ietf.org/mailman/listinfo/lemonade=0A>>Supplemen= tal Web Site:=0A>>http://www.standardstrack.com/ietf/lemonade=0A>>=0A>=0A>= =0A> ---2111173271-216864622-1386109277=:12951 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Dave/Alexy,

I have gone through the https://ietf.org/doc/draft-ietf-qresync-rfc5162bis/ = draft. Regarding the issue reported earlier, some server explicitly expects= ENABLE command to increment the HIGHESTMODSEQ and some server automatically incre= ments. To make the thing clear and also to follow the consistent behavior a= cross various IMAP clients. It would be better to insist a point about enabling the CONDSTORE serv= ice in the server by sending ENABLE CONDSTORE command.

So, even-though server advertises t= he supported capability, its client responsibility to send ENABLE CONDSTORE= command to enable the service. In case, if IMAP server did not support the ENABLE extension, then how client should enable the service can also m= entioned to make it clear for client implementation. 

Please consider and if you feel= its worthy, kindly update the draft. 

Regards,
Jay
From: Dave Cridland <dave@cridland.net>
To: Samsung SVL <samsungsvl@y= ahoo.com>
Cc: Chris Newman <= chris.newman@oracle.com>; "lemonade@ietf.org" <lemonade@ietf.org> =
Sent: Tuesday, 3 Dece= mber 2013, 0:52
Subject: Re: [lemonade] Regarding CONDSTORE IMAP extension

Just to remind folk, the update to RFC 4551 - now also documenting QRE= SYNC as well - is currently in Working Group Last Call, which ends on the 6= th of December.


If you think this = needs to be clearer in the new document, please let the document authors, a= nd the mailing list at imape= xt@ietf.org know.
= =0A

On Tue, Dec 3, 2013 at 12:02 AM, Samsung SVL <samsungsvl@yahoo.com> wrote:
=0A
Hi= Chris,
=0A
<= /span>
Thanks for your clarification.<= /span>
=0A

Regards,
=0A
Jay<= /span>

= =0A
=0A
From: Chris= Newman <ch= ris.newman@oracle.com>
To: Samsung SVL=0A <samsungsvl@yahoo.com>; lemonade@ietf.org
= Sent: Monday, 2 December 2013,= 18:10
=0A
Subject: Re: [lemonade] Regarding C= ONDSTORE IMAP extension

--On December 2, 2013 13:51:24 -0= 800 Samsung SVL <= samsungsvl@yahoo.com>
=0A
wrote:

> Hi All,
>
> Kindly clarify my below query regarding "CONDSTORE" IMAP Extension= .
>
=0A> When IMAP server adverti= ses the "CONDSTORE" support as part of
> CAPABILITIES,= client assumes that server support IMAP CONSTORE
> ex= tension. 
>
=0A> As=0A per R= FC 4551,  client issues SELECT command  for a mailbox in the=
> below format and receives the response with HIGHEST= MODSEQ value as  "1"
>
> C: = A142 SELECT INBOX
=0A>
> During t= he subsequent SELECT command, client receives "HIGHESTMODSEQ"
> value always set to "1". Its not getting incremented with respect= to the
=0A> changes in the mailbox. 
>
> Some IMAP server changes the HIGHESTMODS= EQ value only when client issues
> SELECT command in t= he below format.
>
=0A> C:A142 SE= LECT "INBOX" (QRESYNC ("UIDVALIDITY" "HIGHESTMODSEQ"))
&g= t;
> Kindly clarify which format is right one, because= most of the IMAP server
=0A> behaves differently.&nbs= p;


Technically, the former comma= nd is correct only if you've previously issued
a condsto= re-enabling command (or don't want to use condstore) and the
=0Alatter is correct only if the server advertises QRESYNC and you hav= e issued
"ENABLE QRESYNC" previously. For more details s= ee RFC 4551 and RFC 5162.

Have you tri= ed using:
=0A
C: A142 SELECT INBOX (CO= NDSTORE)

That's a condstore-enabling c= ommand that servers advertising the CONDSTORE
capability= are required to support. Servers are free to not return
=0AHIGHESTMODSEQ at all until a condstore-enabling command occurs, and the= n
they MUST return either HIGHESTMODSEQ or NOMODSEQ.

Of course, if a server is returning HIGHE= STMODSEQ and not updating it after
=0Aflag=0A changes, t= hat server may have a bug, so you may have to fallback to
not using CONDSTORE with that server and just do a full resync every time= .
You might want to report that bug to the server vendor= so they have the
=0Aopportunity to fix it in a subseque= nt release.

     &= nbsp;  - Chris




_________________________________________= ______
=0A=0Alemonade mailing list
=0A<= a rel=3D"nofollow" shape=3D"rect" ymailto=3D"mailto:lemonade@ietf.org" targ= et=3D"_blank" href=3D"mailto:lemonade@ietf.org">lemonade@ietf.org
=0Ahttps://www.ietf.org/ma= ilman/listinfo/lemonade
=0ASupplemental Web Site:
=0Ahttp://www.standardstrack.= com/ietf/lemonade



=
---2111173271-216864622-1386109277=:12951-- From jkt@flaska.net Tue Dec 3 15:00:49 2013 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 451481AE1B8 for ; Tue, 3 Dec 2013 15:00:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.601 X-Spam-Level: X-Spam-Status: No, score=-1.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LzFyeqAcElan for ; Tue, 3 Dec 2013 15:00:47 -0800 (PST) Received: from latimerie.flaska.net (latimerie.flaska.net [IPv6:2a02:2b88:2:1::4a7:333]) by ietfa.amsl.com (Postfix) with ESMTP id 93BF61AE1BC for ; Tue, 3 Dec 2013 15:00:47 -0800 (PST) Received: by latimerie.flaska.net (Postfix, from userid 1000) id 9008863184; Wed, 4 Dec 2013 00:00:40 +0100 (CET) From: =?iso-8859-1?Q?Jan_Kundr=E1t?= To: Date: Wed, 04 Dec 2013 00:00:39 +0100 User-Agent: Trojita/v0.3.96-130-gf259349; Qt/4.8.5; X11; Linux; MIME-Version: 1.0 Message-ID: In-Reply-To: <420444CE-45E0-413C-ADB7-1414EEDF6A42@iki.fi> References: <420444CE-45E0-413C-ADB7-1414EEDF6A42@iki.fi> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Subject: Re: [imapext] I-D Action: draft-ietf-qresync-rfc5162bis-03.txt X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Dec 2013 23:00:49 -0000 On Tuesday, 3 December 2013 21:08:06 CEST, Timo Sirainen wrote: > So Jan isn=E2=80=99t talking about keeping track of which FETCH UID=20 > replies have been sent to client, that would be extra trouble. Thanks, that's exactly what I meant. You are right that talking about=20 messages is clearer than mudding the waters with UIDs -- sorry for this=20 confusion. What about this, then: Note that a VANISHED response without the EARLIER tag (i.e. a VANISHED response caused by EXPUNGE, UID EXPUNGE, or messages expunged in other connections) MUST only refer to a message which was visible to the client at the time VANISHED is sent. That is, servers MUST NOT send send UIDs for previously expunged messages, or messages which were not announced to the client via EXISTS. This means that each UID listed in a VANISHED response results in the client decrementing the message count by one. This is required to prevent a possible race condition where new arrivals for which the UID is not yet known by the client are immediately expunged. For example, if the mailbox contained UIDs 2 and 4, each of the following responses would consitute a broken server implementation: * VANISHED 1 * VANISHED 3 * VANISHED 5 I have the impression that splitting the VANISHED response into VANISHED=20 and VANISHED EARLIER would make sense. These are very different from a=20 client's point of view. If the XML source of the RFC is available, I'm=20 volunteering to make this happen. Cheers, Jan --=20 Trojit=C3=A1, a fast Qt IMAP e-mail client -- http://trojita.flaska.net/ From brong@fastmail.fm Tue Dec 3 15:30:42 2013 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD9091ADF8B for ; Tue, 3 Dec 2013 15:30:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eeZYDLby6GnX for ; Tue, 3 Dec 2013 15:30:38 -0800 (PST) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) by ietfa.amsl.com (Postfix) with ESMTP id 806F81ADF22 for ; Tue, 3 Dec 2013 15:30:38 -0800 (PST) Received: from compute3.internal (compute3.nyi.mail.srv.osa [10.202.2.43]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id 4ED7120A08 for ; Tue, 3 Dec 2013 18:30:35 -0500 (EST) Received: from web4 ([10.202.2.214]) by compute3.internal (MEProxy); Tue, 03 Dec 2013 18:30:35 -0500 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= aFdiMcyHWaxFc/kcgVAnWhNID1U=; b=hBY9r6+IaR+BXNK7nefmFwIP7CZjYfZE as9g3QayuCyP5dYzYUEoDtV5r2ncMWgR2L7oua+uG8EFSWapSpdfaE/sza9QSs4+ HWK2uFk147UdDrMf37bDWvCLY/PAmBrFW/EAVxvNEi7eKsQ7HudmUpaG1UWrqGHj VacRnQgWI2I= 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=aFdiMcyHWaxFc/kcgVAnWhNID1U=; b=Nhq BQH0cvOBFqombXr5eA63atM7K4g4F5UcMYHnKaNASvr5OhsyxTInuOSExip9GbxM X0DY3PfckpD+cH5NEuBa4an4J8FANp++fg4Uu6TsYM48boOLx+JtRquBM4+AS6WQ bDRunha0XByOo4x3M53gnTwJmMIMqA59/feZkdUI= Received: by web4.nyi.mail.srv.osa (Postfix, from userid 99) id 26BBF165A67; Tue, 3 Dec 2013 18:30:35 -0500 (EST) Message-Id: <1386113435.16903.55176845.6FE3D167@webmail.messagingengine.com> X-Sasl-Enc: qqxPaUh8qq/aLacv7NXdMdz/pwO9EBWuGdNAjEIq0St6 1386113435 From: Bron Gondwana To: imapext@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="_----------=_1386113435169032"; charset="utf-8" X-Mailer: MessagingEngine.com Webmail Interface - ajax-24db94df In-Reply-To: <1386109277.12951.YahooMailNeo@web160203.mail.bf1.yahoo.com> References: <1386021084.78345.YahooMailNeo@web160203.mail.bf1.yahoo.com> <9576257CC412C5B483A28644@96B2F16665FF96BAE59E9B90> <1386028949.42306.YahooMailNeo@web160201.mail.bf1.yahoo.com> <1386109277.12951.YahooMailNeo@web160203.mail.bf1.yahoo.com> Date: Wed, 04 Dec 2013 10:30:35 +1100 Subject: Re: [imapext] [lemonade] Regarding CONDSTORE IMAP extension X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Dec 2013 23:30:42 -0000 This is a multi-part message in MIME format. --_----------=_1386113435169032 Content-Transfer-Encoding: 7bit Content-Type: text/plain That doesn't make sense. If the mailbox supports CONDSTORE then it needs to update the MODSEQ on affected messages and the HIGHESTMODSEQ on the mailbox regardless of the source of the change, whether it be a CONDSTORE supported client or not. If it didn't, then other clients wouldn't see the changes. What is possible is to delay the HIGHESTMODSEQ update until a CONDSTORE supporting client connects, and then create a new MODSEQ value for the folder and apply it to every message that has had any change since the last CONDSTORE client connected. As Chris said in the email that you're quoting - the server has a bug. If it returns a HIGHESTMODSEQ value at all, then it MUST increment that value if any message changes. There's no ambiguity here. Regards, Bron. On Wed, Dec 4, 2013, at 09:21 AM, Samsung SVL wrote: Hi Dave/Alexy, I have gone through the [1]https://ietf.org/doc/draft-ietf-qresync-rfc5162bis/ draft. Regarding the issue reported earlier, some server explicitly expects ENABLE command to increment the HIGHESTMODSEQ and some server automatically increments. To make the thing clear and also to follow the consistent behavior across various IMAP clients. It would be better to insist a point about enabling the CONDSTORE service in the server by sending ENABLE CONDSTORE command. So, even-though server advertises the supported capability, its client responsibility to send ENABLE CONDSTORE command to enable the service. In case, if IMAP server did not support the ENABLE extension, then how client should enable the service can also mentioned to make it clear for client implementation. Please consider and if you feel its worthy, kindly update the draft. Regards, Jay __________________________________________________________________ From: Dave Cridland To: Samsung SVL Cc: Chris Newman ; "lemonade@ietf.org" Sent: Tuesday, 3 December 2013, 0:52 Subject: Re: [lemonade] Regarding CONDSTORE IMAP extension Just to remind folk, the update to RFC 4551 - now also documenting QRESYNC as well - is currently in Working Group Last Call, which ends on the 6th of December. [2]https://ietf.org/doc/draft-ietf-qresync-rfc5162bis/ If you think this needs to be clearer in the new document, please let the document authors, and the mailing list at [3]imapext@ietf.org know. On Tue, Dec 3, 2013 at 12:02 AM, Samsung SVL <[4]samsungsvl@yahoo.com> wrote: Hi Chris, Thanks for your clarification. Regards, Jay __________________________________________________________________ From: Chris Newman <[5]chris.newman@oracle.com> To: Samsung SVL <[6]samsungsvl@yahoo.com>; [7]lemonade@ietf.org Sent: Monday, 2 December 2013, 18:10 Subject: Re: [lemonade] Regarding CONDSTORE IMAP extension --On December 2, 2013 13:51:24 -0800 Samsung SVL <[8]samsungsvl@yahoo.com> wrote: > Hi All, > > Kindly clarify my below query regarding "CONDSTORE" IMAP Extension. > > When IMAP server advertises the "CONDSTORE" support as part of > CAPABILITIES, client assumes that server support IMAP CONSTORE > extension. > > As per RFC 4551, client issues SELECT command for a mailbox in the > below format and receives the response with HIGHESTMODSEQ value as "1" > > C: A142 SELECT INBOX > > During the subsequent SELECT command, client receives "HIGHESTMODSEQ" > value always set to "1". Its not getting incremented with respect to the > changes in the mailbox. > > Some IMAP server changes the HIGHESTMODSEQ value only when client issues > SELECT command in the below format. > > C:A142 SELECT "INBOX" (QRESYNC ("UIDVALIDITY" "HIGHESTMODSEQ")) > > Kindly clarify which format is right one, because most of the IMAP server > behaves differently. Technically, the former command is correct only if you've previously issued a condstore-enabling command (or don't want to use condstore) and the latter is correct only if the server advertises QRESYNC and you have issued "ENABLE QRESYNC" previously. For more details see RFC 4551 and RFC 5162. Have you tried using: C: A142 SELECT INBOX (CONDSTORE) That's a condstore-enabling command that servers advertising the CONDSTORE capability are required to support. Servers are free to not return HIGHESTMODSEQ at all until a condstore-enabling command occurs, and then they MUST return either HIGHESTMODSEQ or NOMODSEQ. Of course, if a server is returning HIGHESTMODSEQ and not updating it after flag changes, that server may have a bug, so you may have to fallback to not using CONDSTORE with that server and just do a full resync every time. You might want to report that bug to the server vendor so they have the opportunity to fix it in a subsequent release. - Chris _______________________________________________ lemonade mailing list [9]lemonade@ietf.org [10]https://www.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: [11]http://www.standardstrack.com/ietf/lemonade _______________________________________________ imapext mailing list [12]imapext@ietf.org [13]https://www.ietf.org/mailman/listinfo/imapext -- Bron Gondwana brong@fastmail.fm References 1. https://ietf.org/doc/draft-ietf-qresync-rfc5162bis/ 2. https://ietf.org/doc/draft-ietf-qresync-rfc5162bis/ 3. mailto:imapext@ietf.org 4. mailto:samsungsvl@yahoo.com 5. mailto:chris.newman@oracle.com 6. mailto:samsungsvl@yahoo.com 7. mailto:lemonade@ietf.org 8. mailto:samsungsvl@yahoo.com 9. mailto:lemonade@ietf.org 10. https://www.ietf.org/mailman/listinfo/lemonade 11. http://www.standardstrack.com/ietf/lemonade 12. mailto:imapext@ietf.org 13. https://www.ietf.org/mailman/listinfo/imapext --_----------=_1386113435169032 Content-Transfer-Encoding: 7bit Content-Type: text/html
That doesn't make sense.
 
If the mailbox supports CONDSTORE then it needs to update the MODSEQ on affected messages and the HIGHESTMODSEQ on the mailbox regardless of the source of the change, whether it be a CONDSTORE supported client or not.
 
If it didn't, then other clients wouldn't see the changes.
 
What is possible is to delay the HIGHESTMODSEQ update until a CONDSTORE supporting client connects, and then create a new MODSEQ value for the folder and apply it to every message that has had any change since the last CONDSTORE client connected.
 
As Chris said in the email that you're quoting - the server has a bug.  If it returns a HIGHESTMODSEQ value at all, then it MUST increment that value if any message changes.  There's no ambiguity here.
 
Regards,
 
Bron.
 
 
On Wed, Dec 4, 2013, at 09:21 AM, Samsung SVL wrote:
Hi Dave/Alexy,
 
I have gone through the https://ietf.org/doc/draft-ietf-qresync-rfc5162bis/ draft. Regarding the issue reported earlier, some server explicitly expects ENABLE command to increment the HIGHESTMODSEQ and some server automatically increments. To make the thing clear and also to follow the consistent behavior across various IMAP clients. It would be better to insist a point about enabling the CONDSTORE service in the server by sending ENABLE CONDSTORE command.
 
So, even-though server advertises the supported capability, its client responsibility to send ENABLE CONDSTORE command to enable the service. In case, if IMAP server did not support the ENABLE extension, then how client should enable the service can also mentioned to make it clear for client implementation. 
 
Please consider and if you feel its worthy, kindly update the draft. 
 
Regards,
Jay
 
From: Dave Cridland <dave@cridland.net>
To: Samsung SVL <samsungsvl@yahoo.com>
Cc: Chris Newman <chris.newman@oracle.com>; "lemonade@ietf.org" <lemonade@ietf.org>
Sent: Tuesday, 3 December 2013, 0:52
Subject: Re: [lemonade] Regarding CONDSTORE IMAP extension
 
Just to remind folk, the update to RFC 4551 - now also documenting QRESYNC as well - is currently in Working Group Last Call, which ends on the 6th of December.
 
 
If you think this needs to be clearer in the new document, please let the document authors, and the mailing list at imapext@ietf.org know.
 
 
On Tue, Dec 3, 2013 at 12:02 AM, Samsung SVL <samsungsvl@yahoo.com> wrote:
Hi Chris,
 
Thanks for your clarification.
 
Regards,
Jay
 
From: Chris Newman <chris.newman@oracle.com>
To: Samsung SVL <samsungsvl@yahoo.com>; lemonade@ietf.org
Sent: Monday, 2 December 2013, 18:10
 
Subject: Re: [lemonade] Regarding CONDSTORE IMAP extension
 
--On December 2, 2013 13:51:24 -0800 Samsung SVL <samsungsvl@yahoo.com>
 
wrote:
 
> Hi All,
>
> Kindly clarify my below query regarding "CONDSTORE" IMAP Extension.
>
> When IMAP server advertises the "CONDSTORE" support as part of
> CAPABILITIES, client assumes that server support IMAP CONSTORE
> extension. 
>
> As per RFC 4551,  client issues SELECT command  for a mailbox in the
> below format and receives the response with HIGHESTMODSEQ value as  "1"
>
> C: A142 SELECT INBOX
>
> During the subsequent SELECT command, client receives "HIGHESTMODSEQ"
> value always set to "1". Its not getting incremented with respect to the
> changes in the mailbox. 
>
> Some IMAP server changes the HIGHESTMODSEQ value only when client issues
> SELECT command in the below format.
>
> C:A142 SELECT "INBOX" (QRESYNC ("UIDVALIDITY" "HIGHESTMODSEQ"))
>
> Kindly clarify which format is right one, because most of the IMAP server
> behaves differently. 
 
 
Technically, the former command is correct only if you've previously issued
a condstore-enabling command (or don't want to use condstore) and the
latter is correct only if the server advertises QRESYNC and you have issued
"ENABLE QRESYNC" previously. For more details see RFC 4551 and RFC 5162.
 
Have you tried using:
 
C: A142 SELECT INBOX (CONDSTORE)
 
That's a condstore-enabling command that servers advertising the CONDSTORE
capability are required to support. Servers are free to not return
HIGHESTMODSEQ at all until a condstore-enabling command occurs, and then
they MUST return either HIGHESTMODSEQ or NOMODSEQ.
 
Of course, if a server is returning HIGHESTMODSEQ and not updating it after
flag changes, that server may have a bug, so you may have to fallback to
not using CONDSTORE with that server and just do a full resync every time.
You might want to report that bug to the server vendor so they have the
opportunity to fix it in a subsequent release.
 
        - Chris
 
 
 
 
 
_______________________________________________
lemonade mailing list
Supplemental Web Site:
 
 
 
 
_______________________________________________
imapext mailing list
 
--
Bron Gondwana
brong@fastmail.fm
 
--_----------=_1386113435169032-- From dave@cridland.net Wed Dec 4 00:41:30 2013 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C04931AE098 for ; Wed, 4 Dec 2013 00:41:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id drbuaXRqs5CD for ; Wed, 4 Dec 2013 00:41:29 -0800 (PST) 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 65D1E1AE089 for ; Wed, 4 Dec 2013 00:41:29 -0800 (PST) Received: by mail-oa0-f43.google.com with SMTP id i7so16283193oag.2 for ; Wed, 04 Dec 2013 00:41:26 -0800 (PST) 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=Vn1nsbBAH9Kt4tjBLT5+ocqQuqtmaA5UlfWt3PDhj38=; b=CXZJf2OPPKzdvkk8tv7fmoLDWiwloOVyhYTkOZcbzP/R+IWFyX+TXiJ3CX7MG1PbaC YGCNKP0zHLtIor+15dZNyvf1jj2hYWhw7sNUCePn69tvYeYpWepr7ud6vdthhhV58X3L 5kyVekdEs9qXWjmnQQTbOd9wwCv4/uco9rRKA= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=Vn1nsbBAH9Kt4tjBLT5+ocqQuqtmaA5UlfWt3PDhj38=; b=XXiqGqNW+u+Q24FbliwwWAn8/WFVUrXmL47wMAD5C2VXhqlcsQ18IWrQd2+JkGP4nA q8VIOeL+WNexjzk3xx1cSY7DGz0rpcKxRwkE7c8Ki12JSNj1SSVQmvcKNnYU+C6Z6GJb YBHi+TXwt6k12KHCsAErs4FVUBR9Yeh8X0HYsKvrUXpUxPj2Miu9iQwWw0y6ngDJtSZW 2peDzxVwF2P1IW7/nNvN2yQAvW+WJPYm1DiIhDAxeV+G3oMZqBr3q/trTTDB6plPur0J EPXCKeD9v8lOe7bKPicApjeb58KVewwR646b8fPzC4yXPWM8ewMy9pkQE1NamWmSA755 jzSA== X-Gm-Message-State: ALoCoQkEHN6gN9aLrzWKDVPhoYg8osl3LC5z8WhCBI2QR02ribKJ+yONVUuz3ezc0bkj4uZoZoGK MIME-Version: 1.0 X-Received: by 10.60.51.196 with SMTP id m4mr62529505oeo.1.1386146486331; Wed, 04 Dec 2013 00:41:26 -0800 (PST) Received: by 10.60.121.97 with HTTP; Wed, 4 Dec 2013 00:41:26 -0800 (PST) In-Reply-To: References: Date: Wed, 4 Dec 2013 08:41:26 +0000 Message-ID: From: Dave Cridland To: "imapext@ietf.org" Content-Type: multipart/alternative; boundary=001a11c30920ecbfe504ecb16006 Subject: Re: [imapext] WGLC on QRESYNC, Ending 6th December. X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Dec 2013 08:41:31 -0000 --001a11c30920ecbfe504ecb16006 Content-Type: text/plain; charset=ISO-8859-1 Reminder: This WGLC closes in just two days. If you have reviewed the draft, and have no comments, please let us know. If you have not reviewed the draft, please do so. On Fri, Nov 22, 2013 at 1:54 PM, Dave Cridland wrote: > Folks, > > This begins a two week last call period for > draft-ietf-qresync-rfc5162bis-03.txt. Please submit any comments you have > on or before 6th December 2013. > > I know we have some reviews in progress, we'll deal with the results of > those as they arrive. > > Thanks, > > Dave. > (Ex Cathedra) > --001a11c30920ecbfe504ecb16006 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Reminder: This WGLC closes in just two days.

If you have reviewed the draft, and have no comments, please let us k= now.

If you have not reviewed the draft, please do= so.


On Fri,= Nov 22, 2013 at 1:54 PM, Dave Cridland <dave@cridland.net> = wrote:
Folks,

<= /div>
This begins a two week last call period for draft-ietf-qresync-rf= c5162bis-03.txt. =A0Please submit any comments you have on or before 6th De= cember 2013.

I know we have some reviews in progress, we'll deal with the resul= ts of those as they arrive.

Thanks,

=
Dave.
(Ex Cathedra)

--001a11c30920ecbfe504ecb16006-- From j.sb@sta.samsung.com Wed Dec 4 09:53:14 2013 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FFAE1AE2C0 for ; Wed, 4 Dec 2013 09:53:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h2fVwFRQCfsI for ; Wed, 4 Dec 2013 09:53:11 -0800 (PST) Received: from cuda4.sta.samsung.com (mailedge.sta.samsung.com [63.166.115.23]) by ietfa.amsl.com (Postfix) with ESMTP id 3B11D1ADDBD for ; Wed, 4 Dec 2013 09:53:09 -0800 (PST) X-ASG-Debug-ID: 1386179585-056fcf579954d0a0001-Ao1j2H Received: from StaEx7mb3.telecom.sna.samsung.com ([105.52.12.125]) by cuda4.sta.samsung.com with ESMTP id 5lga4xpH0qnL8mEi; Wed, 04 Dec 2013 11:53:05 -0600 (CST) X-Barracuda-Envelope-From: j.sb@sta.samsung.com X-Barracuda-RBL-Trusted-Forwarder: 105.52.12.125 X-ASG-Whitelist: Client Received: from STAEX7MB3.telecom.sna.samsung.com ([fe80::2da2:a10c:2286:604e]) by StaEx7mb3.telecom.sna.samsung.com ([fe80::2da2:a10c:2286:604e%21]) with mapi; Wed, 4 Dec 2013 11:53:05 -0600 From: Jayantheesh S B X-Barracuda-BWL-IP: fe80::2da2:a10c:2286:604e To: Bron Gondwana , "imapext@ietf.org" Date: Wed, 4 Dec 2013 11:53:04 -0600 Thread-Topic: [imapext] [lemonade] Regarding CONDSTORE IMAP extension X-ASG-Orig-Subj: RE: [imapext] [lemonade] Regarding CONDSTORE IMAP extension Thread-Index: Ac7wzKTQYJC7L11xTMuQWgdMByUQ7gAS9vpA Message-ID: <6C31A20D5301214284D0C838A6B69542CFBD66FC2A@StaEx7mb3.telecom.sna.samsung.com> References: <1386021084.78345.YahooMailNeo@web160203.mail.bf1.yahoo.com> <9576257CC412C5B483A28644@96B2F16665FF96BAE59E9B90> <1386028949.42306.YahooMailNeo@web160201.mail.bf1.yahoo.com> <1386109277.12951.YahooMailNeo@web160203.mail.bf1.yahoo.com> <1386113435.16903.55176845.6FE3D167@webmail.messagingengine.com> In-Reply-To: <1386113435.16903.55176845.6FE3D167@webmail.messagingengine.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_6C31A20D5301214284D0C838A6B69542CFBD66FC2AStaEx7mb3tele_" MIME-Version: 1.0 X-Barracuda-Connect: UNKNOWN[105.52.12.125] X-Barracuda-Start-Time: 1386179585 X-Barracuda-URL: http://65.169.250.23:8000/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sta.samsung.com X-Barracuda-BRTS-Status: 1 Subject: Re: [imapext] [lemonade] Regarding CONDSTORE IMAP extension X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Dec 2013 17:53:14 -0000 --_000_6C31A20D5301214284D0C838A6B69542CFBD66FC2AStaEx7mb3tele_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi All, Based on the below statement from RFC, client can enable the CONDSTORE by s= ending the ENABLE CONDSTORE command. If CONDSTORE supported IMAP server, increments the HIGHESTMODESEQ for any c= hanges in the mailbox automatically without any request from the IMAP client, what would be the use of ENABLE CONDSTORE com= mand to enable the service. Please clarify. A client supporting CONDSTORE extension indicates its willingness to receive mod-sequence updates in all untagged FETCH responses by issuing: an ENABLE command containing "CONDSTORE" as one of the parameters. (This requirement only applies to servers that also implement the ENABLE extension [RFC5161].) Regards, Jay From: Bron Gondwana [mailto:brong@fastmail.fm] Sent: Tuesday, December 03, 2013 6:31 PM To: imapext@ietf.org Subject: Re: [imapext] [lemonade] Regarding CONDSTORE IMAP extension That doesn't make sense. If the mailbox supports CONDSTORE then it needs to update the MODSEQ on aff= ected messages and the HIGHESTMODSEQ on the mailbox regardless of the sourc= e of the change, whether it be a CONDSTORE supported client or not. If it didn't, then other clients wouldn't see the changes. What is possible is to delay the HIGHESTMODSEQ update until a CONDSTORE sup= porting client connects, and then create a new MODSEQ value for the folder = and apply it to every message that has had any change since the last CONDST= ORE client connected. As Chris said in the email that you're quoting - the server has a bug. If = it returns a HIGHESTMODSEQ value at all, then it MUST increment that value = if any message changes. There's no ambiguity here. Regards, Bron. On Wed, Dec 4, 2013, at 09:21 AM, Samsung SVL wrote: Hi Dave/Alexy, I have gone through the https://ietf.org/doc/draft-ietf-qresync-rfc5162bis/= draft. Regarding the issue reported earlier, some server explicitly expect= s ENABLE command to increment the HIGHESTMODSEQ and some server automatical= ly increments. To make the thing clear and also to follow the consistent be= havior across various IMAP clients. It would be better to insist a point ab= out enabling the CONDSTORE service in the server by sending ENABLE CONDSTOR= E command. So, even-though server advertises the supported capability, its client resp= onsibility to send ENABLE CONDSTORE command to enable the service. In case,= if IMAP server did not support the ENABLE extension, then how client shoul= d enable the service can also mentioned to make it clear for client impleme= ntation. Please consider and if you feel its worthy, kindly update the draft. Regards, Jay ________________________________ From: Dave Cridland > To: Samsung SVL > Cc: Chris Newman >;= "lemonade@ietf.org" > Sent: Tuesday, 3 December 2013, 0:52 Subject: Re: [lemonade] Regarding CONDSTORE IMAP extension Just to remind folk, the update to RFC 4551 - now also documenting QRESYNC = as well - is currently in Working Group Last Call, which ends on the 6th of= December. https://ietf.org/doc/draft-ietf-qresync-rfc5162bis/ If you think this needs to be clearer in the new document, please let the d= ocument authors, and the mailing list at imapext@ietf.org know. On Tue, Dec 3, 2013 at 12:02 AM, Samsung SVL > wrote: Hi Chris, Thanks for your clarification. Regards, Jay ________________________________ From: Chris Newman = > To: Samsung SVL >; lemona= de@ietf.org Sent: Monday, 2 December 2013, 18:10 Subject: Re: [lemonade] Regarding CONDSTORE IMAP extension --On December 2, 2013 13:51:24 -0800 Samsung SVL > wrote: > Hi All, > > Kindly clarify my below query regarding "CONDSTORE" IMAP Extension. > > When IMAP server advertises the "CONDSTORE" support as part of > CAPABILITIES, client assumes that server support IMAP CONSTORE > extension. > > As per RFC 4551, client issues SELECT command for a mailbox in the > below format and receives the response with HIGHESTMODSEQ value as "1" > > C: A142 SELECT INBOX > > During the subsequent SELECT command, client receives "HIGHESTMODSEQ" > value always set to "1". Its not getting incremented with respect to the > changes in the mailbox. > > Some IMAP server changes the HIGHESTMODSEQ value only when client issues > SELECT command in the below format. > > C:A142 SELECT "INBOX" (QRESYNC ("UIDVALIDITY" "HIGHESTMODSEQ")) > > Kindly clarify which format is right one, because most of the IMAP server > behaves differently. Technically, the former command is correct only if you've previously issued a condstore-enabling command (or don't want to use condstore) and the latter is correct only if the server advertises QRESYNC and you have issued "ENABLE QRESYNC" previously. For more details see RFC 4551 and RFC 5162. Have you tried using: C: A142 SELECT INBOX (CONDSTORE) That's a condstore-enabling command that servers advertising the CONDSTORE capability are required to support. Servers are free to not return HIGHESTMODSEQ at all until a condstore-enabling command occurs, and then they MUST return either HIGHESTMODSEQ or NOMODSEQ. Of course, if a server is returning HIGHESTMODSEQ and not updating it after flag changes, that server may have a bug, so you may have to fallback to not using CONDSTORE with that server and just do a full resync every time. You might want to report that bug to the server vendor so they have the opportunity to fix it in a subsequent release. - Chris _______________________________________________ lemonade mailing list lemonade@ietf.org https://www.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade _______________________________________________ imapext mailing list imapext@ietf.org https://www.ietf.org/mailman/listinfo/imapext -- Bron Gondwana brong@fastmail.fm --_000_6C31A20D5301214284D0C838A6B69542CFBD66FC2AStaEx7mb3tele_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi = All,

 

Based on the below statemen= t from RFC, client can enable the CONDSTORE by sending the ENABLE CONDSTORE= command.

If CONDST= ORE supported IMAP server, increments the HIGHESTMODESEQ for any changes in= the mailbox automatically without any

request from the IMAP client, what would be the use of = ENABLE CONDSTORE command to enable the service.

 

Please clarify.

A client supporting CONDSTORE extension indicates its w= illingness to

 =   receive mod-sequence updates in all untagged FETCH responses by=

   issuing:

 

 

an ENABLE command containing "CONDSTORE" as one of = the parameters.

&nbs= p;     (This requirement only applies to servers that a= lso implement the

&n= bsp;     ENABLE extension [RFC5161].)=

 

 

Regards,

Jay=

 <= /span>

From: Bron Gondwana [mailto:bron= g@fastmail.fm]
Sent: Tuesday, December 03, 2013 6:31 PM
To= : imapext@ietf.org
Subject: Re: [imapext] [lemonade] Regardin= g CONDSTORE IMAP extension

 

That doesn't make sens= e.

 

If the mailbox supports CONDSTORE then it needs = to update the MODSEQ on affected messages and the HIGHESTMODSEQ on the mail= box regardless of the source of the change, whether it be a CONDSTORE suppo= rted client or not.

 

If it didn't, then other client= s wouldn't see the changes.

&= nbsp;

What is possible is to = delay the HIGHESTMODSEQ update until a CONDSTORE supporting client connects= , and then create a new MODSEQ value for the folder and apply it to every m= essage that has had any change since the last CONDSTORE client connected.

 

As Chris said in the email that you're quoting - the= server has a bug.  If it returns a HIGHESTMODSEQ value at all, then i= t MUST increment that value if any message changes.  There's no ambigu= ity here.

 

Regards,

 

Bron.

 

 

= On Wed, Dec 4, 2013, at 09:21 AM, Samsung SVL wrote:

Hi Dave/Alexy,

 

I have gone through the https://ietf.org/doc/draft-i= etf-qresync-rfc5162bis/ draft. Regarding the issue reported= earlier, some server explicitly expects ENABLE command to increment the HI= GHESTMODSEQ and some server automatically increments. To make the thing cle= ar and also to follow the consistent behavior across various IMAP clients.&= nbsp;It would be better to insist a point about ena= bling the CONDSTORE service in the server by sending ENABLE CONDSTORE comma= nd.

 = ;

So, even-thoug= h server advertises the supported capability, its client responsibility to = send ENABLE CONDSTORE command to enable the service. In case, if IMAP serve= r did not support the ENABLE extension, then how client should enable the s= ervice can also mentioned to make it clear for client implementation. =

 

Please consider and if y= ou feel its worthy, kindly update the draft. 

 

<= p class=3DMsoNormal>Regards,

Jay

 

From: Dave= Cridland <dave@cridland.net>= ;

To: Samsung SVL <samsungsvl@yahoo.com>

Sent: Tuesday, 3 December 2013, 0:52

Subject: Re: [lemonade] Regarding CONDSTORE IMAP extension <= /span>

<= span style=3D'font-family:"Helvetica","sans-serif";color:black'> =

Just to remind folk, the update to RFC 4551 - now also documenting QRESYNC= as well - is currently in Working Group Last Call, which ends on the 6th o= f December.

 

<= span style=3D'font-family:"Helvetica","sans-serif";color:black'> =

If you th= ink this needs to be clearer in the new document, please let the document a= uthors, and the mailing list at imapext@ietf.org know.

 

 

=

On Tue, Dec 3, 2013 a= t 12:02 AM, Samsung SVL <samsungsvl@yahoo.com> wrote:

=

Hi Chris,

 

Thanks for your clarification.

 =

Regar= ds,

Jay

 

From: Chris Newman <chris.newman@oracle.com= >

To: Samsung SVL <samsungsvl@yahoo.com= >; lemonade@ietf.= org
Sent: Monday, 2 December 2013, 18:10<= /span>

&= nbsp;

Subject: Re: [lemonade] Regarding CONDSTORE IMAP extension =

&nbs= p;

--On December 2, 2013 13:51:24 -0800 Samsung SVL <samsungsvl@yahoo.com>

 =

wrot= e:

&n= bsp;

= > Hi All,

> 

> Kindly clarify my below query regarding "CONDSTORE&= quot; IMAP Extension.

> 

> When IMAP server advertises the "CONDSTORE= " support as part of

> CAPABILITIES, client assumes that server support = IMAP CONSTORE

> extension. 

> 

> As per RFC 4551,  client iss= ues SELECT command  for a mailbox in the

> below format and receives the= response with HIGHESTMODSEQ value as  "1"=

> =

> C: A142 SE= LECT INBOX

> 

> During the subsequent SELECT command, client receives &quo= t;HIGHESTMODSEQ"

> value always set to "1". Its not getting in= cremented with respect to the

> changes in the mailbox. 

> 

> Some IMAP= server changes the HIGHESTMODSEQ value only when client issues<= /span>

> SELECT comm= and in the below format.

> 

> C:A142 SELECT "INBOX" (QRESYNC (&q= uot;UIDVALIDITY" "HIGHESTMODSEQ"))

> 

> Kindly clarify whic= h format is right one, because most of the IMAP server

> behaves differently.=  

 

 

Technically, the former command is correct only if you've previously = issued

a condstore-enabling command (or don't want to use condstore) and the

latter= is correct only if the server advertises QRESYNC and you have issued =

"ENA= BLE QRESYNC" previously. For more details see RFC 4551 and RFC 5162.

 =

Have= you tried using:

 

C: A142 SELECT INBOX (CONDSTORE)

=

 

That's a condstore-enabling co= mmand that servers advertising the CONDSTORE

capability are required to support= . Servers are free to not return

HIGHESTMODSEQ at all until a condstore-enabli= ng command occurs, and then

they MUST return either HIGHESTMODSEQ or NOMODSEQ.<= o:p>

 = ;

Of = course, if a server is returning HIGHESTMODSEQ and not updating it after

flag c= hanges, that server may have a bug, so you may have to fallback to

not using CO= NDSTORE with that server and just do a full resync every time. <= /span>

You might want t= o report that bug to the server vendor so they have the <= /p>

opportunity to fix it= in a subsequent release.

 

        - Chris

<= span style=3D'font-family:"Helvetica","sans-serif";color:black'> =

 

 <= o:p>

=

 

&= nbsp;

_______________________________________________

lemonade mailing list

Supplemental Web Site:

=

 

=

 

 <= /span>

 

_______________________________________________

imapext mailing list

 

--

Bron Gondwana

&n= bsp;

= --_000_6C31A20D5301214284D0C838A6B69542CFBD66FC2AStaEx7mb3tele_-- From dave@cridland.net Wed Dec 4 09:58:46 2013 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B3371AE2C0 for ; Wed, 4 Dec 2013 09:58:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oschAon1YEYC for ; Wed, 4 Dec 2013 09:58:44 -0800 (PST) Received: from mail-ob0-x232.google.com (mail-ob0-x232.google.com [IPv6:2607:f8b0:4003:c01::232]) by ietfa.amsl.com (Postfix) with ESMTP id BDC111AE26D for ; Wed, 4 Dec 2013 09:58:44 -0800 (PST) Received: by mail-ob0-f178.google.com with SMTP id uz6so16333186obc.23 for ; Wed, 04 Dec 2013 09:58:41 -0800 (PST) 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 :cc:content-type; bh=e/roeCTmIBqPuia1OyDNKzMm2RUm6tzTAaOMFGreL9o=; b=UA+eFa8uVfYsAPJ7CVYOzFE/y4b3MRX90LeRrlaje123xjx+6tiov97p4pcUiKVKm4 nXKbwNIWIjTt85rIv7InsFPQNWXF+zoPYAbn6dhQkMRoqu7r7qAMIKYtBhzMm4Xdkx/X TsGiLU9aH944y3/uYSFUwr8YgsjmW5cjarL+M= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=e/roeCTmIBqPuia1OyDNKzMm2RUm6tzTAaOMFGreL9o=; b=JcmZunjZwlfE4Kvr7+WkVNxa2BsCxNz4z7VwLPX84Ype4ku7yEd0+NtgTiLHax/ABH VTrjE40MtDXG/JqcdG23rW78psvMfo7sBXjRxtx22kIWJPDMz9KGq67fuSddnmgy7T3J LtDQANneV+EtSjlTh/ojypETWuEz07D8bQdCJa21mR3DEQBMv0gFVVE1i166/5xRTllF 1ylbP8YjsHNSs39iW4ZI0nSr3vzu9efGZx3fKiFCIhJywH2PvFaXJDLadnA4UVjXYCyJ LKixh5sU7bDtbDygBQcml1BE1t9+uw/bdN4Jn5lLm1umfrRXpp3PATBOS6iGxddEUQQE eEZw== X-Gm-Message-State: ALoCoQnnnshzzUU0VjcTHvWKYrLTMvr4XKfLLxEHNRRPFk8boc+ZrHvbC1JaZawiI3YDczbU7vQ7 MIME-Version: 1.0 X-Received: by 10.60.95.135 with SMTP id dk7mr25383548oeb.11.1386179921673; Wed, 04 Dec 2013 09:58:41 -0800 (PST) Received: by 10.60.121.97 with HTTP; Wed, 4 Dec 2013 09:58:41 -0800 (PST) In-Reply-To: <6C31A20D5301214284D0C838A6B69542CFBD66FC2A@StaEx7mb3.telecom.sna.samsung.com> References: <1386021084.78345.YahooMailNeo@web160203.mail.bf1.yahoo.com> <9576257CC412C5B483A28644@96B2F16665FF96BAE59E9B90> <1386028949.42306.YahooMailNeo@web160201.mail.bf1.yahoo.com> <1386109277.12951.YahooMailNeo@web160203.mail.bf1.yahoo.com> <1386113435.16903.55176845.6FE3D167@webmail.messagingengine.com> <6C31A20D5301214284D0C838A6B69542CFBD66FC2A@StaEx7mb3.telecom.sna.samsung.com> Date: Wed, 4 Dec 2013 17:58:41 +0000 Message-ID: From: Dave Cridland To: Jayantheesh S B Content-Type: multipart/alternative; boundary=089e011603c6d3a87e04ecb92963 Cc: Bron Gondwana , "imapext@ietf.org" Subject: Re: [imapext] [lemonade] Regarding CONDSTORE IMAP extension X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Dec 2013 17:58:46 -0000 --089e011603c6d3a87e04ecb92963 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Dec 4, 2013 at 5:53 PM, Jayantheesh S B wrote: > Hi All, > > > > Based on the below statement from RFC, client can enable the CONDSTORE by > sending the ENABLE CONDSTORE command. > > If CONDSTORE supported IMAP server, increments the HIGHESTMODESEQ for any > changes in the mailbox automatically without any > > request from the IMAP client, what would be the use of ENABLE CONDSTORE > command to enable the service. > > > I think you've not quite understood what the passage you quote states. > Please clarify. > > A client supporting CONDSTORE extension indicates its willingness to > > receive mod-sequence updates in all untagged FETCH responses by > > issuing: > > > > > > an ENABLE command containing "CONDSTORE" as one of the parameters. > > (This requirement only applies to servers that also implement the > > ENABLE extension [RFC5161].) > > > > So ENABLE enables the use of that extension's protocol changes for the rest of that session. It doesn't cause the server to start performing the extension's requirements internally; a server can choose to do that at any time - but one any client has used condstore with a mailbox, it has to continue performing those requirements. Does that help? Dave. --089e011603c6d3a87e04ecb92963 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Wed, Dec 4, 2013 at 5:53 PM, Jayantheesh S B <j.sb= @sta.samsung.com> wrote:

Hi All,=

=A0

<= p class=3D"MsoNormal" style=3D"line-height:14.4pt">Based on the below statement f= rom RFC, client can enable the CONDSTORE by sending the ENABLE CONDSTORE co= mmand.

If CONDSTORE supported IMAP s= erver, increments the HIGHESTMODESEQ for any changes in the mailbox automat= ically without any

request from the IMAP client,= what would be the use of ENABLE CONDSTORE command to enable the service. <= u>

=A0


I think you've not quite understoo= d what the passage you quote states.
=A0

=

Please clarify.

A client supporting CONDSTORE extension indicates its = willingness to

=A0=A0 receive mod-sequence u= pdates in all untagged FETCH responses by

=A0=A0= issuing:

=A0

=A0

<= p class=3D"MsoNormal" style=3D"line-height:14.4pt">an ENABLE command containing "CONDSTORE" as one of the= parameters.

=A0=A0=A0=A0=A0 (This require= ment only applies to servers that also implement the

=A0=A0= =A0=A0=A0 ENABLE extension [RFC5161].)

=A0

=


So ENABLE enabl= es the use of that extension's protocol changes for the rest of that se= ssion.

It doesn't cause the server to start performing the= extension's requirements internally; a server can choose to do that at= any time - but one any client has used condstore with a mailbox, it has to= continue performing those requirements.

Does that help?

Dave.
--089e011603c6d3a87e04ecb92963-- From j.sb@sta.samsung.com Wed Dec 4 11:56:21 2013 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AA341AD8E1 for ; Wed, 4 Dec 2013 11:56:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tg4J6P6iak2s for ; Wed, 4 Dec 2013 11:56:18 -0800 (PST) Received: from cuda4.sta.samsung.com (mailedge.sta.samsung.com [63.166.115.23]) by ietfa.amsl.com (Postfix) with ESMTP id 9AD0B1ACCDF for ; Wed, 4 Dec 2013 11:56:18 -0800 (PST) X-ASG-Debug-ID: 1386186974-056fcf31dfa27e70001-Ao1j2H Received: from StaEx7mb3.telecom.sna.samsung.com ([105.52.12.125]) by cuda4.sta.samsung.com with ESMTP id HGAWc9a9NOKl5oSS; Wed, 04 Dec 2013 13:56:14 -0600 (CST) X-Barracuda-Envelope-From: j.sb@sta.samsung.com X-Barracuda-RBL-Trusted-Forwarder: 105.52.12.125 X-ASG-Whitelist: Client Received: from STAEX7MB3.telecom.sna.samsung.com ([fe80::2da2:a10c:2286:604e]) by StaEx7mb3.telecom.sna.samsung.com ([fe80::2da2:a10c:2286:604e%21]) with mapi; Wed, 4 Dec 2013 13:56:14 -0600 From: Jayantheesh S B X-Barracuda-BWL-IP: fe80::2da2:a10c:2286:604e To: Dave Cridland Date: Wed, 4 Dec 2013 13:56:13 -0600 Thread-Topic: [imapext] [lemonade] Regarding CONDSTORE IMAP extension X-ASG-Orig-Subj: RE: [imapext] [lemonade] Regarding CONDSTORE IMAP extension Thread-Index: Ac7xGniFHQ6jO4p+R8G5uVO6m5sWFAADyYRg Message-ID: <6C31A20D5301214284D0C838A6B69542CFBD66FC60@StaEx7mb3.telecom.sna.samsung.com> References: <1386021084.78345.YahooMailNeo@web160203.mail.bf1.yahoo.com> <9576257CC412C5B483A28644@96B2F16665FF96BAE59E9B90> <1386028949.42306.YahooMailNeo@web160201.mail.bf1.yahoo.com> <1386109277.12951.YahooMailNeo@web160203.mail.bf1.yahoo.com> <1386113435.16903.55176845.6FE3D167@webmail.messagingengine.com> <6C31A20D5301214284D0C838A6B69542CFBD66FC2A@StaEx7mb3.telecom.sna.samsung.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_6C31A20D5301214284D0C838A6B69542CFBD66FC60StaEx7mb3tele_" MIME-Version: 1.0 X-Barracuda-Connect: UNKNOWN[105.52.12.125] X-Barracuda-Start-Time: 1386186974 X-Barracuda-URL: http://65.169.250.23:8000/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sta.samsung.com X-Barracuda-BRTS-Status: 1 Cc: Bron Gondwana , "imapext@ietf.org" Subject: Re: [imapext] [lemonade] Regarding CONDSTORE IMAP extension X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Dec 2013 19:56:21 -0000 --_000_6C31A20D5301214284D0C838A6B69542CFBD66FC60StaEx7mb3tele_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thanks Dave for your detailed explanation. Coming to my initial question. If IMAP server advertises the CONDSTORE capa= bility indicates the support of IMAP CONDSTORE extension. * For SELECT/EXAMINE command IMAP server should send the HIGHESTMOD= ESQ value modified with respect to change in the mailbox (Or) * IMAP Client should send ENABLE CONDSTORE to enable the service fo= r that session to get the correct HIGHESTMODSEQ value from server. Please clarify. Regards, Jay From: Dave Cridland [mailto:dave@cridland.net] Sent: Wednesday, December 04, 2013 12:59 PM To: Jayantheesh S B Cc: Bron Gondwana; imapext@ietf.org Subject: Re: [imapext] [lemonade] Regarding CONDSTORE IMAP extension On Wed, Dec 4, 2013 at 5:53 PM, Jayantheesh S B > wrote: Hi All, Based on the below statement from RFC, client can enable the CONDSTORE by s= ending the ENABLE CONDSTORE command. If CONDSTORE supported IMAP server, increments the HIGHESTMODESEQ for any c= hanges in the mailbox automatically without any request from the IMAP client, what would be the use of ENABLE CONDSTORE com= mand to enable the service. I think you've not quite understood what the passage you quote states. Please clarify. A client supporting CONDSTORE extension indicates its willingness to receive mod-sequence updates in all untagged FETCH responses by issuing: an ENABLE command containing "CONDSTORE" as one of the parameters. (This requirement only applies to servers that also implement the ENABLE extension [RFC5161].) So ENABLE enables the use of that extension's protocol changes for the rest= of that session. It doesn't cause the server to start performing the extension's requirement= s internally; a server can choose to do that at any time - but one any clie= nt has used condstore with a mailbox, it has to continue performing those r= equirements. Does that help? Dave. --_000_6C31A20D5301214284D0C838A6B69542CFBD66FC60StaEx7mb3tele_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Thanks Da= ve for your detailed explanation.

 

Coming to = my initial question. If IMAP server advertises the CONDSTORE capability ind= icates the support of IMAP CONDSTORE extension.

 

·         <= ![endif]>For SELECT/EXAMINE command IMAP server should send the HIGH= ESTMODESQ value modified with respect to change in the mailbox

(Or= )

&m= iddot;    =      IMAP Client = should send ENABLE CONDSTORE to enable the service for that session to get = the correct HIGHESTMODSEQ value from server.

 

Please clarify.

&nb= sp;

Regards,<= /p>

Jay

Fro= m: Dave Cridland [mailto:dave@cridland.net]
Sent: Wednesday, = December 04, 2013 12:59 PM
To: Jayantheesh S B
Cc: Bron= Gondwana; imapext@ietf.org
Subject: Re: [imapext] [lemonade] Reg= arding CONDSTORE IMAP extension

<= o:p> 

On Wed, Dec 4, 2013 at 5:53 P= M, Jayantheesh S B <j.sb@sta.samsung.com> wrote:

Hi All,

 

Based on t= he below statement from RFC, client can enable the CONDSTORE by sending the= ENABLE CONDSTORE command.

= If CONDSTORE sup= ported IMAP server, increments the HIGHESTMODESEQ for any changes in the ma= ilbox automatically without any

request fro= m the IMAP client, what would be the use of ENABLE CONDSTORE command to ena= ble the service.

 

 

<= /div>

I think you've not quite understood what the= passage you quote states.

&n= bsp;

Please clarify.

A client= supporting CONDSTORE extension indicates its willingness to

   receive mod-sequence updates in all untagged = FETCH responses by

   issuing:

 

 

an ENABLE co= mmand containing "CONDSTORE" as one of the parameters.

      (This requiremen= t only applies to servers that also implement the

      ENABLE extension [RFC5161].)

 

<= /div>

 

So ENABLE enables the use of that extension's protoco= l changes for the rest of that session.

 

It doesn'= t cause the server to start performing the extension's requirements interna= lly; a server can choose to do that at any time - but one any client has us= ed condstore with a mailbox, it has to continue performing those requiremen= ts.

 

Does that help?

 

Dave.

= --_000_6C31A20D5301214284D0C838A6B69542CFBD66FC60StaEx7mb3tele_-- From dave@cridland.net Wed Dec 4 12:09:06 2013 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDA501AE2D0 for ; Wed, 4 Dec 2013 12:09:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tlEfZO-Sr8Ro for ; Wed, 4 Dec 2013 12:09:05 -0800 (PST) Received: from mail-ob0-x22e.google.com (mail-ob0-x22e.google.com [IPv6:2607:f8b0:4003:c01::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 2B5601AE333 for ; Wed, 4 Dec 2013 12:09:05 -0800 (PST) Received: by mail-ob0-f174.google.com with SMTP id wn1so16768079obc.33 for ; Wed, 04 Dec 2013 12:09:02 -0800 (PST) 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 :cc:content-type; bh=xtVtnIMNHUy0Ex98z5JcJNJlAaNCw1gNNe716FO4f5U=; b=Zb2nfWRDnE3mRwzK345O75UGW4R+MkKXnUBVCRiU0y+zkPE0/kXSkSIEBBxEaxLy+o tKgj1KB2scbu2JcPqXeOMZ1PYP4MhGSRpY4Lvaj606rAId6Epaz6c3Jbz0Bkj1vCuRSf 3Gve48iKyY76h6EnzmIP9cIw7mnWaEtqXaolo= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=xtVtnIMNHUy0Ex98z5JcJNJlAaNCw1gNNe716FO4f5U=; b=ittef5i2wX1UgBU8qyPgJEozs0/LzX1XMxHYOvKbLrpUvwJBaWPn0+RylCizY87jFI QLpDQGTiSogp2RfLw1y0qXbhd3g8ENQhlr7Lq4+65GFXvGnK7s9jzao0uURCuCXE6JOQ ACdUF/3ypZzvZv9+BSmC/vvTSYItcGpYvFFYGp8CBOLqexGQ22X27Ry9iRGDI+nzjziw JXITXpKNdUc43vo03hfyyfigrAbFJRQ4ZBUNT71zWNb34bHRZSBA7vy8WAHY3KG+B1s6 DvnjfR5QegYYHbY2zW1CEsAvXWa4U/awL1rR5cDAGb2s3uK8KVA6FMo8oi2g+nYnXslt ChEA== X-Gm-Message-State: ALoCoQmWnJ82MaK0nYLuKawOYI59Rs+wL5ftBSJYKUtFLQ3HfporuMfTNQnjPOiraUVwW8tEjHJS MIME-Version: 1.0 X-Received: by 10.60.42.72 with SMTP id m8mr2640834oel.64.1386187742016; Wed, 04 Dec 2013 12:09:02 -0800 (PST) Received: by 10.60.121.97 with HTTP; Wed, 4 Dec 2013 12:09:01 -0800 (PST) In-Reply-To: <6C31A20D5301214284D0C838A6B69542CFBD66FC60@StaEx7mb3.telecom.sna.samsung.com> References: <1386021084.78345.YahooMailNeo@web160203.mail.bf1.yahoo.com> <9576257CC412C5B483A28644@96B2F16665FF96BAE59E9B90> <1386028949.42306.YahooMailNeo@web160201.mail.bf1.yahoo.com> <1386109277.12951.YahooMailNeo@web160203.mail.bf1.yahoo.com> <1386113435.16903.55176845.6FE3D167@webmail.messagingengine.com> <6C31A20D5301214284D0C838A6B69542CFBD66FC2A@StaEx7mb3.telecom.sna.samsung.com> <6C31A20D5301214284D0C838A6B69542CFBD66FC60@StaEx7mb3.telecom.sna.samsung.com> Date: Wed, 4 Dec 2013 20:09:01 +0000 Message-ID: From: Dave Cridland To: Jayantheesh S B Content-Type: multipart/alternative; boundary=089e01536b14f48bc004ecbafb73 Cc: "imapext@ietf.org" Subject: Re: [imapext] [lemonade] Regarding CONDSTORE IMAP extension X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Dec 2013 20:09:07 -0000 --089e01536b14f48bc004ecbafb73 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Wed, Dec 4, 2013 at 7:56 PM, Jayantheesh S B wrote= : > Thanks Dave for your detailed explanation. > > > > Coming to my initial question. If IMAP server advertises the CONDSTORE > capability indicates the support of IMAP CONDSTORE extension. > > > > =B7 For SELECT/EXAMINE command IMAP server should send the > HIGHESTMODESQ value modified with respect to change in the mailbox > > (Or) > > =B7 IMAP Client should send ENABLE CONDSTORE to enable the servic= e > for that session to get the correct HIGHESTMODSEQ value from server. > > > > Please clarify. > > > Can I first check if you've read the latest draft: http://datatracker.ietf.org/doc/draft-ietf-qresync-rfc4551bis/ I'm hoping this should make the protocol clearer, and if it's still not clear from this document, we should be addressing this now. Dave. --089e01536b14f48bc004ecbafb73 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Wed, Dec 4, 2013 at 7:56 PM, Jayantheesh S B <j.sb= @sta.samsung.com> wrote:
Thanks Dave for your detailed explanation.

=A0

Coming to my initial question. If IMAP serve= r advertises the CONDSTORE capability indicates the support of IMAP CONDSTO= RE extension.

=A0

=B7<= span style=3D"font-style:normal;font-variant:normal;font-weight:normal;font= -size:7pt;line-height:normal;font-family:'Times New Roman'">=A0=A0= =A0=A0=A0=A0=A0=A0 For SELECT/EXAMINE c= ommand IMAP server should send the HIGHESTMODESQ value modified with respec= t to change in the mailbox

(Or)

<= /u><= span>=B7IMAP Client = should send ENABLE CONDSTORE to enable the service for that session to get = the correct HIGHESTMODSEQ value from server.

=A0

Please clarify.



Can I first check if you've read the latest draft:

http://datatracker.ietf.org/doc/draft-ietf-qresync-rfc4551bis/

I'm hoping this should make the protocol clearer, a= nd if it's still not clear from this document, we should be addressing = this now.

Dave.=A0
--089e01536b14f48bc004ecbafb73-- From j.sb@sta.samsung.com Thu Dec 5 08:27:08 2013 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F11DD1AE0D5 for ; Thu, 5 Dec 2013 08:27:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pr__vYj9Ox8L for ; Thu, 5 Dec 2013 08:27:05 -0800 (PST) Received: from cuda4.sta.samsung.com (mailedge.sta.samsung.com [63.166.115.23]) by ietfa.amsl.com (Postfix) with ESMTP id 8FCD11AE0AA for ; Thu, 5 Dec 2013 08:27:05 -0800 (PST) X-ASG-Debug-ID: 1386260821-056fcf57995b0210001-Ao1j2H Received: from StaEx7mb3.telecom.sna.samsung.com ([105.52.12.125]) by cuda4.sta.samsung.com with ESMTP id ZmGcHBJXkTfBuaNN; Thu, 05 Dec 2013 10:27:01 -0600 (CST) X-Barracuda-Envelope-From: j.sb@sta.samsung.com X-Barracuda-RBL-Trusted-Forwarder: 105.52.12.125 X-ASG-Whitelist: Client Received: from STAEX7MB3.telecom.sna.samsung.com ([fe80::2da2:a10c:2286:604e]) by StaEx7mb3.telecom.sna.samsung.com ([fe80::2da2:a10c:2286:604e%21]) with mapi; Thu, 5 Dec 2013 10:27:01 -0600 From: Jayantheesh S B X-Barracuda-BWL-IP: fe80::2da2:a10c:2286:604e To: Dave Cridland Date: Thu, 5 Dec 2013 10:27:00 -0600 Thread-Topic: [imapext] [lemonade] Regarding CONDSTORE IMAP extension X-ASG-Orig-Subj: RE: [imapext] [lemonade] Regarding CONDSTORE IMAP extension Thread-Index: Ac7xLK3NtS90XcAwTcWG/f4LQCFlEAAqgV1g Message-ID: <6C31A20D5301214284D0C838A6B69542CFBD66FD91@StaEx7mb3.telecom.sna.samsung.com> References: <1386021084.78345.YahooMailNeo@web160203.mail.bf1.yahoo.com> <9576257CC412C5B483A28644@96B2F16665FF96BAE59E9B90> <1386028949.42306.YahooMailNeo@web160201.mail.bf1.yahoo.com> <1386109277.12951.YahooMailNeo@web160203.mail.bf1.yahoo.com> <1386113435.16903.55176845.6FE3D167@webmail.messagingengine.com> <6C31A20D5301214284D0C838A6B69542CFBD66FC2A@StaEx7mb3.telecom.sna.samsung.com> <6C31A20D5301214284D0C838A6B69542CFBD66FC60@StaEx7mb3.telecom.sna.samsung.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_6C31A20D5301214284D0C838A6B69542CFBD66FD91StaEx7mb3tele_" MIME-Version: 1.0 X-Barracuda-Connect: UNKNOWN[105.52.12.125] X-Barracuda-Start-Time: 1386260821 X-Barracuda-URL: http://65.169.250.23:8000/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sta.samsung.com X-Barracuda-BRTS-Status: 1 Cc: "imapext@ietf.org" Subject: Re: [imapext] [lemonade] Regarding CONDSTORE IMAP extension X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Dec 2013 16:27:08 -0000 --_000_6C31A20D5301214284D0C838A6B69542CFBD66FD91StaEx7mb3tele_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thanks Dave. It's clear in http://datatracker.ietf.org/doc/draft-ietf-qresync-rfc4551bis= / draft. Regards, Jay From: Dave Cridland [mailto:dave@cridland.net] Sent: Wednesday, December 04, 2013 3:09 PM To: Jayantheesh S B Cc: imapext@ietf.org Subject: Re: [imapext] [lemonade] Regarding CONDSTORE IMAP extension On Wed, Dec 4, 2013 at 7:56 PM, Jayantheesh S B > wrote: Thanks Dave for your detailed explanation. Coming to my initial question. If IMAP server advertises the CONDSTORE capa= bility indicates the support of IMAP CONDSTORE extension. * For SELECT/EXAMINE command IMAP server should send the HIGHESTMOD= ESQ value modified with respect to change in the mailbox (Or) * IMAP Client should send ENABLE CONDSTORE to enable the service fo= r that session to get the correct HIGHESTMODSEQ value from server. Please clarify. Can I first check if you've read the latest draft: http://datatracker.ietf.org/doc/draft-ietf-qresync-rfc4551bis/ I'm hoping this should make the protocol clearer, and if it's still not cle= ar from this document, we should be addressing this now. Dave. --_000_6C31A20D5301214284D0C838A6B69542CFBD66FD91StaEx7mb3tele_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Thanks Da= ve.

 

It’s clear in http://datatr= acker.ietf.org/doc/draft-ietf-qresync-rfc4551bis/ draft.<= o:p>

 

Regards,

<= span style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F= 497D'>Jay

From: Dave Cridland [mai= lto:dave@cridland.net]
Sent: Wednesday, December 04, 2013 3:09 P= M
To: Jayantheesh S B
Cc: imapext@ietf.org
Subjec= t: Re: [imapext] [lemonade] Regarding CONDSTORE IMAP extension

 

On Wed, Dec 4, 2013 at 7:56 PM, Jayantheesh S B <j.sb@sta.samsung.com> wrote= :

Thanks Dave for your detailed explanation.

 

Co= ming to my initial question. If IMAP server advertises the CONDSTORE capabi= lity indicates the support of IMAP CONDSTORE extension. <= /p>

 

·         <= /span>For SELECT/EXAMINE command IMAP server should send the HIGHEST= MODESQ value modified with respect to change in the mailbox

(Or)

·    &= nbsp;    IMAP Client should send ENABLE CONDST= ORE to enable the service for that session to get the correct HIGHESTMODSEQ= value from server.

 

Please clarify.

&nb= sp;

 =

Can I first check if you've read = the latest draft:

 =

 

I'm hoping this s= hould make the protocol clearer, and if it's still not clear from this docu= ment, we should be addressing this now.

 

Dave.&nbs= p;

= --_000_6C31A20D5301214284D0C838A6B69542CFBD66FD91StaEx7mb3tele_-- From dave@cridland.net Thu Dec 5 10:01:56 2013 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7D501AE123 for ; Thu, 5 Dec 2013 10:01:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ghFi-qidoGEu for ; Thu, 5 Dec 2013 10:01:55 -0800 (PST) Received: from mail-ob0-x231.google.com (mail-ob0-x231.google.com [IPv6:2607:f8b0:4003:c01::231]) by ietfa.amsl.com (Postfix) with ESMTP id EDD131AE128 for ; Thu, 5 Dec 2013 10:01:54 -0800 (PST) Received: by mail-ob0-f177.google.com with SMTP id va2so17839877obc.8 for ; Thu, 05 Dec 2013 10:01:51 -0800 (PST) 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 :cc:content-type; bh=Za5Wb6m1gTJ/i7f5kymGsKUnjtViXvGwnBntomumJD4=; b=XDYQ6mSQxnTekhmGk7sXf2KfLfLzmEZaJ8dEIDYGKjcmzCS+0N9H6ypKkWE1jIGI7x f2aea57BNpDsuy5imod1ZygnYEaiuqkcIOQn4g5jT8el95mfXNdXE1IR8olO1ts4ufIn RrGZNQh7CE3PHUMyXe525C+ETYMsnQMel2xbQ= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=Za5Wb6m1gTJ/i7f5kymGsKUnjtViXvGwnBntomumJD4=; b=XE5QRMI8OEPWWhr5CoORDMBL0oF2bv9njKToaGG/TMTfOOi2muRB9UXREcU9M5WZY7 mDMVbr0VPqVLlMZWbtTerreCOPBHCpxUgqEgh7vUTjRTY+kqeaDRHENDI7obHfwC9W8+ Ism5TM6CmT0OCPdiTKsjIeLB8cHL1eM7IOxFtAtkPwoQaVBAa47UiPI75Iro+6S/b7Mo 7Bz0xaHAbIodGY7kYy+/HqRyv6RKQpv/ZacZxCK6co8NCWPvF8BqMWgte6D1fqhj25Sg YvtMy7Rk7hie60QAeq8LUijKy+WbR7KkHlC63UlYdtzCw18cAj1RkXhACjaXdR/K/LCJ jR8w== X-Gm-Message-State: ALoCoQnsPb20YInwHs5EeL/25LXplLGGO7LBBleazMIWbxsxV4/Gwgu7ncn57eJ65ykhN0P5AnPy MIME-Version: 1.0 X-Received: by 10.182.84.132 with SMTP id z4mr16316778oby.49.1386266511310; Thu, 05 Dec 2013 10:01:51 -0800 (PST) Received: by 10.60.121.97 with HTTP; Thu, 5 Dec 2013 10:01:51 -0800 (PST) In-Reply-To: <6C31A20D5301214284D0C838A6B69542CFBD66FD91@StaEx7mb3.telecom.sna.samsung.com> References: <1386021084.78345.YahooMailNeo@web160203.mail.bf1.yahoo.com> <9576257CC412C5B483A28644@96B2F16665FF96BAE59E9B90> <1386028949.42306.YahooMailNeo@web160201.mail.bf1.yahoo.com> <1386109277.12951.YahooMailNeo@web160203.mail.bf1.yahoo.com> <1386113435.16903.55176845.6FE3D167@webmail.messagingengine.com> <6C31A20D5301214284D0C838A6B69542CFBD66FC2A@StaEx7mb3.telecom.sna.samsung.com> <6C31A20D5301214284D0C838A6B69542CFBD66FC60@StaEx7mb3.telecom.sna.samsung.com> <6C31A20D5301214284D0C838A6B69542CFBD66FD91@StaEx7mb3.telecom.sna.samsung.com> Date: Thu, 5 Dec 2013 18:01:51 +0000 Message-ID: From: Dave Cridland To: Jayantheesh S B Content-Type: multipart/alternative; boundary=089e0111c09af8e4e204eccd5225 Cc: "imapext@ietf.org" Subject: Re: [imapext] [lemonade] Regarding CONDSTORE IMAP extension X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Dec 2013 18:01:57 -0000 --089e0111c09af8e4e204eccd5225 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On Thu, Dec 5, 2013 at 4:27 PM, Jayantheesh S B wrote= : > Thanks Dave. > > > > It=92s clear in > http://datatracker.ietf.org/doc/draft-ietf-qresync-rfc4551bis/ draft. > > Thanks, that's really helpful - have you read the entire draft, and do you have any further comments? The Working Group Last Call ends tomorrow, and it'd be particularly good to get any comments from a new implementor at this stage. Dave. --089e0111c09af8e4e204eccd5225 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
On Thu, Dec 5, 2013 at 4:27 PM, Jayantheesh S B <j.sb= @sta.samsung.com> wrote:

Thanks Dave. =

=A0<= /p>

It=92s clear in http://datatracker.ietf.org/doc/draft-ietf-qresync-rfc45= 51bis/ draft.

<= /div>

Thanks, that's really helpful - h= ave you read the entire draft, and do you have any further comments?

The Working Group Last Call ends tomorrow, and it'd= be particularly good to get any comments from a new implementor at this st= age.

Dave.
--089e0111c09af8e4e204eccd5225-- From brong@fastmail.fm Thu Dec 5 15:59:54 2013 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7D1F1AE11B for ; Thu, 5 Dec 2013 15:59:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lHlWobCebEOq for ; Thu, 5 Dec 2013 15:59:50 -0800 (PST) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) by ietfa.amsl.com (Postfix) with ESMTP id 114F51ADF59 for ; Thu, 5 Dec 2013 15:59:49 -0800 (PST) Received: from compute6.internal (compute6.nyi.mail.srv.osa [10.202.2.46]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id 6B4CA20EB1 for ; Thu, 5 Dec 2013 18:59:46 -0500 (EST) Received: from web2 ([10.202.2.212]) by compute6.internal (MEProxy); Thu, 05 Dec 2013 18:59:46 -0500 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= I09+KdzybPSW+8gF4sJ0sjdOziM=; b=dQ6zqcQ5DE4ctNqIm48udsBatlVtFLvA ZCI9j/e9aPR5MrKYT+CuBt04qacCg4DY/LeUZSv8gV1/EiaiiFJD92jAMf1AsLEQ RRScECDFSmi4obBihFciC+jmxGgk8P6Etpt6qeU4//Pbnkben/WNC1DFtp7do1FU sAwejw+AhpE= 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=I09+KdzybPSW+8gF4sJ0sjdOziM=; b=Olb MVlk5Zn8q4hooM7F+WX+7hSg4qYEYDXN0hXEMQkStykPRk7cPp3IPkQG5i9RT6j4 d5YtFK0rxqBO0t1uH+0EnarwRm+vfo1fNrz1vPLUQvo77O98C5pU3hZwY/W9kBdt o9xwlirdSmWJjfSRL1GDu5AoiCrYRQk3Dj8oazmc= Received: by web2.nyi.mail.srv.osa (Postfix, from userid 99) id 42CB7540091; Thu, 5 Dec 2013 18:59:46 -0500 (EST) Message-Id: <1386287986.3881.56114933.3A3FC70D@webmail.messagingengine.com> X-Sasl-Enc: 9kxrrYwL255/EXpW2cKTOmIDRgEtALcGeCzZlKs6n+kK 1386287986 From: Bron Gondwana To: imapext@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="_----------=_138628798638812"; charset="utf-8" X-Mailer: MessagingEngine.com Webmail Interface - ajax-c99dcdd8 In-Reply-To: References: Date: Fri, 06 Dec 2013 10:59:46 +1100 Subject: Re: [imapext] WGLC on QRESYNC, Ending 6th December. X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Dec 2013 23:59:54 -0000 This is a multi-part message in MIME format. --_----------=_138628798638812 Content-Transfer-Encoding: 7bit Content-Type: text/plain I'm sorry I haven't taken the time to do a really thorough reading of the latest draft earlier! I've noted a couple of spots that I should double-check the Cyrus implementation. I notice that METADATA/ANNOTATE-EXPERIMENT-1 aren't addressed at all. That certainly makes things simpler, but for those of us who _do_ implement it... I'm just treating it exactly like like flags - any change to anything updates the entire message MODSEQ. We're not keeping separate MODSEQ values on annotations (yet). I only have one significant worry - and it starts in section 3.2. The UNCHANGEDSINCE atomicity requirements are only on a single keyword at a time. So starting here: "If the mod-sequence of any metadata item on the message is equal to or less than... then the requested operation is performed" My reading of that (any rather than every) is that you could do this: C: TAG STORE 5 (UNCHANGED SINCE 5674) +FLAGS.SILENT ($FlagA $FlagB) on a server which stores separate per-flag modseq, and get this response: S: * 5 FETCH (UID 23 MODSEQ (5801) FLAGS ($FlagA)) S: TAG OK [MODIFIED 5] Conditional Store failed Where $FlagA gets set, but another session had set/removed $FlagB already. ----- Here's a real world example. A client uses the following keywords: Junk NotJunk JunkRecorded. When it marks a message a junk it sets both JunkRecorded and ONLY ONE of Junk or NotJunk. A brand new mailbox has one message. S: * 1 FETCH (UID 1 MODSEQ (1) FLAGS ()) The first client marks the message as Junk C: a01 STORE 1 (UNCHANGED SINCE 1) +FLAGS (Junk JunkRecorded) S: * 1 FETCH (UID 1 MODSEQ (2) FLAGS (Junk JunkRecorded)) S: TAG OK Conditional Store completed And a second client marks the message as NonJunk C: a01 STORE 1 (UNCHANGED SINCE 1) +FLAGS (NonJunk JunkRecorded) S: * 1 FETCH (UID 1 MODSEQ (3) FLAGS (Junk JunkRecorded NonJunk)) S: TAG OK [Modified 1] Conditional Store failed .... clearly the end result is bogus - but this is what I see as the logical result of allowing partial metadata updates to succeed "atomically" when other metadata was unchanged. In this case the 'NonJunk' flag was unchanged since MODSEQ 1 - and the 'JunkRecorded' flag, which was supposed to protect against this problem, has failed. Am I reading it wrong? I would be a lot more comfortable if all metadata about a message was unchanged if ANY of the requested operations were disallowed by the UNCHANGEDSINCE rule. (none of this applies in Cyrus, which only stores on MODSEQ per message... but I still worry) Regards, Bron. On Wed, Dec 4, 2013, at 07:41 PM, Dave Cridland wrote: Reminder: This WGLC closes in just two days. If you have reviewed the draft, and have no comments, please let us know. If you have not reviewed the draft, please do so. On Fri, Nov 22, 2013 at 1:54 PM, Dave Cridland <[1]dave@cridland.net> wrote: Folks, This begins a two week last call period for draft-ietf-qresync-rfc5162bis-03.txt. Please submit any comments you have on or before 6th December 2013. I know we have some reviews in progress, we'll deal with the results of those as they arrive. Thanks, Dave. (Ex Cathedra) _______________________________________________ imapext mailing list [2]imapext@ietf.org [3]https://www.ietf.org/mailman/listinfo/imapext -- Bron Gondwana brong@fastmail.fm References 1. mailto:dave@cridland.net 2. mailto:imapext@ietf.org 3. https://www.ietf.org/mailman/listinfo/imapext --_----------=_138628798638812 Content-Transfer-Encoding: 7bit Content-Type: text/html
I'm sorry I haven't taken the time to do a really thorough reading of the latest draft earlier! 
 
I've noted a couple of spots that I should double-check the Cyrus implementation.
 
I notice that METADATA/ANNOTATE-EXPERIMENT-1 aren't addressed at all.  That certainly makes things simpler, but for those of us who _do_ implement it... I'm just treating it exactly like like flags - any change to anything updates the entire message MODSEQ.  We're not keeping separate MODSEQ values on annotations (yet).
 
I only have one significant worry - and it starts in section 3.2.  The UNCHANGEDSINCE atomicity requirements are only on a single keyword at a time.
 
So starting here:
 
"If the mod-sequence of any metadata item on the message is equal to or less than... then the requested operation is performed"
 
My reading of that (any rather than every) is that you could do this:
 
C: TAG STORE 5 (UNCHANGED SINCE 5674) +FLAGS.SILENT ($FlagA $FlagB)
 
on a server which stores separate per-flag modseq, and get this response:
 
S: * 5 FETCH (UID 23 MODSEQ (5801) FLAGS ($FlagA))
S: TAG OK [MODIFIED 5] Conditional Store failed
 
Where $FlagA gets set, but another session had set/removed $FlagB already.
 
-----
 
Here's a real world example.  A client uses the following keywords:  Junk NotJunk JunkRecorded.  When it marks a message a junk it sets both JunkRecorded and ONLY ONE of Junk or NotJunk.
 
A brand new mailbox has one message.
 
S: * 1 FETCH (UID 1 MODSEQ (1) FLAGS ())
 
The first client marks the message as Junk
 
C: a01 STORE 1 (UNCHANGED SINCE 1) +FLAGS (Junk JunkRecorded)
S: * 1 FETCH (UID 1 MODSEQ (2) FLAGS (Junk JunkRecorded))
S: TAG OK Conditional Store completed
 
And a second client marks the message as NonJunk
 
C: a01 STORE 1 (UNCHANGED SINCE 1) +FLAGS (NonJunk JunkRecorded)
S: * 1 FETCH (UID 1 MODSEQ (3) FLAGS (Junk JunkRecorded NonJunk))
S: TAG OK [Modified 1] Conditional Store failed
 
.... clearly the end result is bogus - but this is what I see as the logical result of allowing partial metadata updates to succeed "atomically" when other metadata was unchanged.  In this case the 'NonJunk' flag was unchanged since MODSEQ 1 - and the 'JunkRecorded' flag, which was supposed to protect against this problem, has failed.
 
Am I reading it wrong?
 
I would be a lot more comfortable if all metadata about a message was unchanged if ANY of the requested operations were disallowed by the UNCHANGEDSINCE rule.
 
(none of this applies in Cyrus, which only stores on MODSEQ per message... but I still worry)
 
Regards,
 
Bron.
 
 
On Wed, Dec 4, 2013, at 07:41 PM, Dave Cridland wrote:
Reminder: This WGLC closes in just two days.
 
If you have reviewed the draft, and have no comments, please let us know.
 
If you have not reviewed the draft, please do so.
 
 
On Fri, Nov 22, 2013 at 1:54 PM, Dave Cridland <dave@cridland.net> wrote:
 
Folks,
 
This begins a two week last call period for draft-ietf-qresync-rfc5162bis-03.txt.  Please submit any comments you have on or before 6th December 2013.
 
I know we have some reviews in progress, we'll deal with the results of those as they arrive.
 
Thanks,
 
Dave.
(Ex Cathedra)
 
_______________________________________________
imapext mailing list
 
--
Bron Gondwana
brong@fastmail.fm
 
--_----------=_138628798638812-- From alexey.melnikov@isode.com Fri Dec 6 03:43:54 2013 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 862F51ADF50 for ; Fri, 6 Dec 2013 03:43:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.47 X-Spam-Level: X-Spam-Status: No, score=-0.47 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, HTML_MESSAGE=0.001, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x-TxR-lpI8q3 for ; Fri, 6 Dec 2013 03:43:53 -0800 (PST) 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 C1AF41ADF4E for ; Fri, 6 Dec 2013 03:43:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1386330228; d=isode.com; s=selector; i=@isode.com; bh=n3awH/e9J0Hdcj4b09BeDEopgvgziFArcU5dB7Hm6Ws=; 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=ocsXCgfidNYN8L7WPhsQleCwPAXiRg1a6vBR4pngkgJ2KWYlWCglwLvEagZ/i6X1nQmlnY xdDW6w7vuV09Z5+Q4errpavnPWNmJbPHPIwLw3zmn31MmSgQcJ6TZpSza9JPqRFGnpRleW 0LDg2gYPWZ8vD0nevSGJ9WJmFU4+cME=; Received: from [172.16.1.29] (richard.isode.com [62.3.217.249]) by waldorf.isode.com (submission channel) via TCP with ESMTPA id ; Fri, 6 Dec 2013 11:43:47 +0000 Message-ID: <52A1B873.2000402@isode.com> Date: Fri, 06 Dec 2013 11:43:47 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 To: Dave Cridland , Jayantheesh S B References: <1386021084.78345.YahooMailNeo@web160203.mail.bf1.yahoo.com> <9576257CC412C5B483A28644@96B2F16665FF96BAE59E9B90> <1386028949.42306.YahooMailNeo@web160201.mail.bf1.yahoo.com> <1386109277.12951.YahooMailNeo@web160203.mail.bf1.yahoo.com> <1386113435.16903.55176845.6FE3D167@webmail.messagingengine.com> <6C31A20D5301214284D0C838A6B69542CFBD66FC2A@StaEx7mb3.telecom.sna.samsung.com> <6C31A20D5301214284D0C838A6B69542CFBD66FC60@StaEx7mb3.telecom.sna.samsung.com> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------070801010904020608020808" Cc: "imapext@ietf.org" Subject: Re: [imapext] [lemonade] Regarding CONDSTORE IMAP extension X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Dec 2013 11:43:54 -0000 --------------070801010904020608020808 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: quoted-printable On 04/12/2013 20:09, Dave Cridland wrote: > On Wed, Dec 4, 2013 at 7:56 PM, Jayantheesh S B > wrote: > > Thanks Dave for your detailed explanation. > > Coming to my initial question. If IMAP server advertises the > CONDSTORE capability indicates the support of IMAP CONDSTORE > extension. > > =B7For SELECT/EXAMINE command IMAP server should send the > HIGHESTMODESQ value modified with respect to change in the mailbox > > (Or) > > =B7IMAP Client should send ENABLE CONDSTORE to enable the service > for that session to get the correct HIGHESTMODSEQ value from server. > > Please clarify. > I think this is still an open issue which I haven't addressed in the=20 document. Some people seem to have preference for the latter behaviour,=20 but some servers implemented the former. > Can I first check if you've read the latest draft: > > http://datatracker.ietf.org/doc/draft-ietf-qresync-rfc4551bis/ > > I'm hoping this should make the protocol clearer, and if it's still=20 > not clear from this document, we should be addressing this now. > --------------070801010904020608020808 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 04/12/2013 20:09, Dave Cridland wrote:
On Wed, Dec 4, 2013 at 7:56 PM, Jayantheesh S B <j.sb@sta.samsung.com> wrote:

Thanks Dave for your detailed explanation.

 

Coming to my initial question. If IMAP server advertises the CONDSTORE capability indicates the support of IMAP CONDSTORE extension.

 

·         For SELECT/EXAMINE command IMAP server should send the HIGHESTMODESQ value modified with respect to change in the mailbox

(Or)

·         IMAP Client should send ENABLE CONDSTORE to enable the service for that session to get the correct HIGHESTMODSEQ value from server.

 

Please clarify.

I think this is still an open issue which I haven't addressed in the document. Some people seem to have preference for the latter behaviour, but some servers implemented the former.

Can I first check if you've read the latest draft:


I'm hoping this should make the protocol clearer, and if it's still not clear from this document, we should be addressing this now.


--------------070801010904020608020808-- From j.sb@sta.samsung.com Fri Dec 6 08:30:09 2013 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6ECB71AE05C for ; Fri, 6 Dec 2013 08:30:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LFbWAqJIBwsN for ; Fri, 6 Dec 2013 08:30:07 -0800 (PST) Received: from cuda4.sta.samsung.com (mailedge.sta.samsung.com [63.166.115.23]) by ietfa.amsl.com (Postfix) with ESMTP id A496D1AE054 for ; Fri, 6 Dec 2013 08:30:06 -0800 (PST) X-ASG-Debug-ID: 1386347401-056fcf31dfaed280001-Ao1j2H Received: from staEX7mb4.telecom.sna.samsung.com ([105.52.12.130]) by cuda4.sta.samsung.com with ESMTP id NgPFUA8AFzHpLNag; Fri, 06 Dec 2013 10:30:01 -0600 (CST) X-Barracuda-Envelope-From: j.sb@sta.samsung.com X-Barracuda-RBL-Trusted-Forwarder: 105.52.12.130 X-ASG-Whitelist: Client Received: from STAEX7MB3.telecom.sna.samsung.com ([fe80::2da2:a10c:2286:604e]) by staEX7mb4.telecom.sna.samsung.com ([fe80::4869:6c8b:e85a:6ce7%11]) with mapi; Fri, 6 Dec 2013 10:30:01 -0600 From: Jayantheesh S B X-Barracuda-BWL-IP: fe80::2da2:a10c:2286:604e To: Alexey Melnikov , Dave Cridland Date: Fri, 6 Dec 2013 10:29:59 -0600 Thread-Topic: [imapext] [lemonade] Regarding CONDSTORE IMAP extension X-ASG-Orig-Subj: RE: [imapext] [lemonade] Regarding CONDSTORE IMAP extension Thread-Index: Ac7yeG6c91zkBG0tToSQwaCUSolZrgAJ1gIA Message-ID: <6C31A20D5301214284D0C838A6B69542CFBD66FF4B@StaEx7mb3.telecom.sna.samsung.com> References: <1386021084.78345.YahooMailNeo@web160203.mail.bf1.yahoo.com> <9576257CC412C5B483A28644@96B2F16665FF96BAE59E9B90> <1386028949.42306.YahooMailNeo@web160201.mail.bf1.yahoo.com> <1386109277.12951.YahooMailNeo@web160203.mail.bf1.yahoo.com> <1386113435.16903.55176845.6FE3D167@webmail.messagingengine.com> <6C31A20D5301214284D0C838A6B69542CFBD66FC2A@StaEx7mb3.telecom.sna.samsung.com> <6C31A20D5301214284D0C838A6B69542CFBD66FC60@StaEx7mb3.telecom.sna.samsung.com> <52A1B873.2000402@isode.com> In-Reply-To: <52A1B873.2000402@isode.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_6C31A20D5301214284D0C838A6B69542CFBD66FF4BStaEx7mb3tele_" MIME-Version: 1.0 X-Barracuda-Connect: UNKNOWN[105.52.12.130] X-Barracuda-Start-Time: 1386347401 X-Barracuda-URL: http://65.169.250.23:8000/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sta.samsung.com X-Barracuda-BRTS-Status: 1 Cc: "imapext@ietf.org" Subject: Re: [imapext] [lemonade] Regarding CONDSTORE IMAP extension X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Dec 2013 16:30:09 -0000 --_000_6C31A20D5301214284D0C838A6B69542CFBD66FF4BStaEx7mb3tele_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Alexey, Thanks for your response. As a IMAP client implementer, to avoid any interoperability issue, we have = modified our client to send ENABLE CONDSTORE, if IMAP server advertises the= ENABLE and CONDSTORE IMAP extension as part of CAPABILITY response. This solves the problem for us irrespective of IMAP server implementation. Regards, Jay From: Alexey Melnikov [mailto:alexey.melnikov@isode.com] Sent: Friday, December 06, 2013 6:44 AM To: Dave Cridland; Jayantheesh S B Cc: imapext@ietf.org Subject: Re: [imapext] [lemonade] Regarding CONDSTORE IMAP extension On 04/12/2013 20:09, Dave Cridland wrote: On Wed, Dec 4, 2013 at 7:56 PM, Jayantheesh S B > wrote: Thanks Dave for your detailed explanation. Coming to my initial question. If IMAP server advertises the CONDSTORE capa= bility indicates the support of IMAP CONDSTORE extension. * For SELECT/EXAMINE command IMAP server should send the HIGHESTMOD= ESQ value modified with respect to change in the mailbox (Or) * IMAP Client should send ENABLE CONDSTORE to enable the service fo= r that session to get the correct HIGHESTMODSEQ value from server. Please clarify. I think this is still an open issue which I haven't addressed in the docume= nt. Some people seem to have preference for the latter behaviour, but some = servers implemented the former. Can I first check if you've read the latest draft: http://datatracker.ietf.org/doc/draft-ietf-qresync-rfc4551bis/ I'm hoping this should make the protocol clearer, and if it's still not cle= ar from this document, we should be addressing this now. --_000_6C31A20D5301214284D0C838A6B69542CFBD66FF4BStaEx7mb3tele_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

= Hi Alexey,

&nb= sp;

Thanks for your response. <= o:p>

 

As a IMAP client implementer, to avoid any in= teroperability issue, we have modified our client to send ENABLE CONDSTORE,= if IMAP server advertises the ENABLE and CONDSTORE IMAP extension as part = of CAPABILITY response.

<= o:p> 

This solves the prob= lem for us irrespective of IMAP server implementation.

 

Regards,

Jay

From: Alexey Melnikov [mailto:alexey.melnikov@isode.com]
S= ent: Friday, December 06, 2013 6:44 AM
To: Dave Cridland; Jay= antheesh S B
Cc: imapext@ietf.org
Subject: Re: [imapext= ] [lemonade] Regarding CONDSTORE IMAP extension

=

 

O= n 04/12/2013 20:09, Dave Cridland wrote:

On W= ed, Dec 4, 2013 at 7:56 PM, Jayantheesh S B <j.sb@sta.samsung.com> wrote:

Thanks Dave for your detailed explanation.

 

Coming to my= initial question. If IMAP server advertises the CONDSTORE capability indic= ates the support of IMAP CONDSTORE extension.

=  

·         For SELECT/EXAMINE command IMAP server should send the HIGHESTMODESQ val= ue modified with respect to change in the mailbox

(Or)

·     &nbs= p;   IMAP Client should send ENABLE CONDSTORE to en= able the service for that session to get the correct HIGHESTMODSEQ value fr= om server.

 

<= p class=3DMsoNormal style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:= auto'>Please clarify.

I think this is still = an open issue which I haven't addressed in the document. Some people seem t= o have preference for the latter behaviour, but some servers implemented th= e former.


Can I first check if you've read the latest draft:

 

 

I'm hoping this should make the protocol clearer, and if = it's still not clear from this document, we should be addressing this now.<= o:p>

 

<= /div>

 

= --_000_6C31A20D5301214284D0C838A6B69542CFBD66FF4BStaEx7mb3tele_-- From slusarz@horde.org Fri Dec 6 16:16:23 2013 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07EA91AE0EA for ; Fri, 6 Dec 2013 16:16:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BCmVRK8oO4ys for ; Fri, 6 Dec 2013 16:16:21 -0800 (PST) Received: from qmta06.emeryville.ca.mail.comcast.net (qmta06.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:43:76:96:30:56]) by ietfa.amsl.com (Postfix) with ESMTP id EFD9E1AD7BF for ; Fri, 6 Dec 2013 16:16:20 -0800 (PST) Received: from omta10.emeryville.ca.mail.comcast.net ([76.96.30.28]) by qmta06.emeryville.ca.mail.comcast.net with comcast id yQA81m0040cQ2SLA6QGH1u; Sat, 07 Dec 2013 00:16:17 +0000 Received: from bigworm.curecanti.org ([71.229.167.0]) by omta10.emeryville.ca.mail.comcast.net with comcast id yQGF1m00300qwSn8WQGFBS; Sat, 07 Dec 2013 00:16:16 +0000 Received: from bigworm.curecanti.org (localhost.localdomain [IPv6:::1]) (Authenticated sender: slusarz) by bigworm.curecanti.org (Postfix) with ESMTPSA id 4277468068 for ; Fri, 6 Dec 2013 17:16:14 -0700 (MST) Received: from schrute.curecanti.org (schrute.curecanti.org [172.18.5.4]) by bigworm.curecanti.org (Horde Framework) with HTTP; Fri, 06 Dec 2013 17:16:14 -0700 Date: Fri, 06 Dec 2013 17:16:14 -0700 Message-ID: <20131206171614.Horde.I3inQX4SvzGsmVDXyHl8fg9@bigworm.curecanti.org> From: Michael M Slusarz To: imapext@ietf.org References: <20131008141122.25649.73956.idtracker@ietfa.amsl.com> In-Reply-To: <20131008141122.25649.73956.idtracker@ietfa.amsl.com> User-Agent: Internet Messaging Program (IMP) H5 (6.2.0-git) Accept-Language: en X-Originating-IP: 172.18.5.4 X-Remote-Browser: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:25.0) Gecko/20100101 Firefox/25.0 Content-Type: text/plain; charset=UTF-8; format=flowed; DelSp=Yes MIME-Version: 1.0 Content-Disposition: inline DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1386375377; bh=72JjvswYOETxFL8OvnLXgflRt+uraa2vYgCcV4o638c=; h=Received:Received:Received:Received:Date:Message-ID:From:To: Subject:Content-Type:MIME-Version; b=fhGedvAwHMMDntVu+upjvWbba3YWdkOf//Ya3LpVk3cv3L2V4vIqIJTT6mA6wAPAI M4Jt8PmSXXRaGQ2bVky/PovKJTaKXWqbYPGeN/Aj+ptYY45YfT2ssJtrU+B/bzmA+6 KGxyjn4kCMcKoqDKkQmvTiJNtS7YW7MWgt8Yr/8Plb3aQyIcX5ifq1pFm5xTXHY5go S8k/V0jKwbphx1VcF/g7uIkK68o3vEcgjXTOrzfczc1SIbenKTZt7d+BYGtSacFiOI dA5X99xlQ8YIoqWhqgs4evEtQ9Km2Xws0bvxlC1kk3Djr0QmsCscxOpL/orM99NCUP zwGTE0AO4Wsvw== Subject: Re: [imapext] I-D Action: draft-ietf-qresync-rfc5162bis-03.txt X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Dec 2013 00:16:23 -0000 Last minute suggestions, mostly editorial: * Abstract: The first two paragraphs are a lengthy description on CONDSTORE behavior with respect to multiple IMAP clients accessing/altering a common mailbox (a "protected update mechanism"). That seems to be a rarer use-case; the majority of IMAP users are using a single client to access personal mailboxes vs. the more specialized use of a "message queue". To me, the more important real-world usage of CONDSTORE is the ability to quickly and accurately sync flag changes and/or the more general ability to accurately determine if a mailbox has been altered via HIGHESTMODSEQ. I suggest this should be mentioned first instead of second. * Regarding HIGHESTMODSEQ/NOMODSEQ: the document uses the language "the OK untagged response". That can be a bit confusing when reading since it can be interpreted as SELECT/EXAMINE only containing a single untagged OK response. Understood that someone needs to be familiar with 3501 before being able to interpret this document, but wondering if the phrase "an OK untagged response" should be used instead. To me, this more clearly indicates that HIGHESTMODSEQ/NOMODSEQ needs to appear in one of the (possibly multiple) OK responses. * All examples referring to MODSEQs: The examples can be a bit hard to visually parse given large MODSEQ numbers, since it is not readily apparent the relationship between the various MODSEQ values. Example 3: C: a103 UID STORE 6,4,8 (UNCHANGEDSINCE 12121230045) +FLAGS.SILENT (\Deleted) S: * 1 FETCH (UID 4 MODSEQ (12121231000)) S: * 2 FETCH (UID 6 MODSEQ (12121230852)) S: * 4 FETCH (UID 8 MODSEQ (12121130956)) S: a103 OK Conditional Store completed In this example, the '1212123' prefix is noise that makes it difficult to determine the relationship between the significant digits in the MODSEQs. On first glance, it is not easy to see that 12121230852 > 12121230045. To me, at least, simpler MODSEQs make for an easier understanding that all UIDs specified in the STORE command were in fact changed: C: a103 UID STORE 6,4,8 (UNCHANGEDSINCE 5) +FLAGS.SILENT (\Deleted) S: * 1 FETCH (UID 4 MODSEQ (6)) S: * 2 FETCH (UID 6 MODSEQ (7)) S: * 4 FETCH (UID 8 MODSEQ (8)) S: a103 OK Conditional Store completed * UID information in FETCH responses is only required if QRESYNC is enabled (3.2.3). However, the only examples of what happens when an external agent triggers an unsolicited FETCH response appear in the CONDSTORE section, and it doesn't include UID information. E.g., from Page 17: C: C360 NOOP S: * 7 FETCH (FLAGS (\Deleted) MODSEQ (12121245160)) S: C360 OK Noop completed While discussing QRESYNC prospectively within the CONDSTORE definition might be a bit confusing, it is also the logical place to do so given the current examples. At least a mention might be made to 3.2.3: 'Note that this FETCH response MUST include UID data if both a "CONDSTORE enabling command" has been issued and QRESYNC is supported by the server'. * Section 3.2.2 typo: "REQUIREd" should be "REQUIRED". * Section 3.2.5: Document indicates BAD tagged response should be issued if VANISHED UID FETCH modifier is either used with a FETCH command or if ENABLE QRESYNC has not been issued. For completeness, this should also be made clear for the instance where the VANISHED modifier is either used without CHANGEDSINCE -or- an additional UID FETCH modifier is used: The VANISHED UID FETCH modifier MUST only be specified together with the CHANGEDSINCE UID FETCH modifier. If the VANISHED UID FETCH modifier is used without the CHANGEDSINCE UID FETCH modifier, or if additional UID FETCH modifiers besides CHANGEDSINCE and VANISHED are used, the server MUST respond with a tagged BAD response. michael ___________________________________ Michael Slusarz [slusarz@horde.org] From slusarz@horde.org Fri Dec 6 16:56:57 2013 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8D9C1AE169 for ; Fri, 6 Dec 2013 16:56:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5Uae_F3B3xWN for ; Fri, 6 Dec 2013 16:56:56 -0800 (PST) Received: from qmta01.emeryville.ca.mail.comcast.net (qmta01.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:43:76:96:30:16]) by ietfa.amsl.com (Postfix) with ESMTP id 4A4B11AE13A for ; Fri, 6 Dec 2013 16:56:56 -0800 (PST) Received: from omta16.emeryville.ca.mail.comcast.net ([76.96.30.72]) by qmta01.emeryville.ca.mail.comcast.net with comcast id yNWq1m0031ZMdJ4A1Qwscc; Sat, 07 Dec 2013 00:56:52 +0000 Received: from bigworm.curecanti.org ([71.229.167.0]) by omta16.emeryville.ca.mail.comcast.net with comcast id yQwq1m00j00qwSn8cQwrNS; Sat, 07 Dec 2013 00:56:52 +0000 Received: from bigworm.curecanti.org (localhost.localdomain [IPv6:::1]) (Authenticated sender: slusarz) by bigworm.curecanti.org (Postfix) with ESMTPSA id 3598268068 for ; Fri, 6 Dec 2013 17:56:20 -0700 (MST) Received: from schrute.curecanti.org (schrute.curecanti.org [172.18.5.4]) by bigworm.curecanti.org (Horde Framework) with HTTP; Fri, 06 Dec 2013 17:56:20 -0700 Date: Fri, 06 Dec 2013 17:56:20 -0700 Message-ID: <20131206175620.Horde.ix0PtAsRkTI_thz72gWfaQ1@bigworm.curecanti.org> From: Michael M Slusarz To: imapext@ietf.org References: <20131008141122.25649.73956.idtracker@ietfa.amsl.com> <20131206171614.Horde.I3inQX4SvzGsmVDXyHl8fg9@bigworm.curecanti.org> In-Reply-To: <20131206171614.Horde.I3inQX4SvzGsmVDXyHl8fg9@bigworm.curecanti.org> User-Agent: Internet Messaging Program (IMP) H5 (6.2.0-git) Accept-Language: en X-Originating-IP: 172.18.5.4 X-Remote-Browser: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:25.0) Gecko/20100101 Firefox/25.0 Content-Type: text/plain; charset=UTF-8; format=flowed; DelSp=Yes MIME-Version: 1.0 Content-Disposition: inline DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1386377812; bh=xz6mG3EXi5rqyyetGuYCCKBhjktPGaJErVyXpvZfvfg=; h=Received:Received:Received:Received:Date:Message-ID:From:To: Subject:Content-Type:MIME-Version; b=DYt02cMgHy/kz5nI3wmQ8nhOBt8Tv/yGUin+yyyiDU7swuCa6rcUN64z2wEpPyNx7 r3GUwEuBqfCRlSEj+qzu8QiqbfCuYMwxzpj+gmjSGU8zYoi41oMUQQhFOY9A3WAdqL EqIAX2Gc209sJAZafbbKR5y4btiEF84+sU8sBqBpbUnzKeyJx9TdfAHsK4ZKCEYVkv P5FboTUzM8SZgm+10uT92JNGe5Ao6dCjliafcAwHPu+iNazsymsCY2oytY3mQTZRfW U2i8bmgUPE7bDLvOjVGXedalMSOtNGrpS9Saki278sva+g1NLt/Kiph5vEzPHGIYyM AES0+1huCDc0g== Subject: Re: [imapext] I-D Action: draft-ietf-qresync-rfc5162bis-03.txt X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Dec 2013 00:56:58 -0000 Quoting Michael M Slusarz : > Example 3: > > C: a103 UID STORE 6,4,8 (UNCHANGEDSINCE 12121230045) > +FLAGS.SILENT (\Deleted) > S: * 1 FETCH (UID 4 MODSEQ (12121231000)) > S: * 2 FETCH (UID 6 MODSEQ (12121230852)) > S: * 4 FETCH (UID 8 MODSEQ (12121130956)) > S: a103 OK Conditional Store completed On further review: isn't this example wrong? Why is UID 8 returned? It has a MODSEQ lower than the UNCHANGEDSINCE value, so it didn't fail the UNCHANGEDSINCE test. Therefore, it must have already had the \Deleted flag set. Since .SILENT was specified, only the messages that had flag data altered should be returned in FETCH untagged responses (UIDs 4,6). The correct example should be: C: a103 UID STORE 6,4,8 (UNCHANGEDSINCE 12121230045) +FLAGS.SILENT (\Deleted) S: * 1 FETCH (UID 4 MODSEQ (12121231000)) S: * 2 FETCH (UID 6 MODSEQ (12121230852)) S: a103 OK Conditional Store completed Or maybe this was intended: C: a103 UID STORE 6,4,8 (UNCHANGEDSINCE 12121230045) +FLAGS.SILENT (\Deleted) S: * 1 FETCH (UID 4 MODSEQ (12121231000)) S: * 2 FETCH (UID 6 MODSEQ (12121230852)) S: * 4 FETCH (UID 8 MODSEQ (12121230956)) S: a103 OK Conditional Store completed (i.e. MODSEQ 12121*2*30956 instead of 12121*1*30956. This is a good example of why simpler MODSEQ examples might be preferable). michael ___________________________________ Michael Slusarz [slusarz@horde.org] From alexey.melnikov@isode.com Mon Dec 9 03:03:10 2013 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32A491AE260 for ; Mon, 9 Dec 2013 03:03:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8_cGChZ1dMPx for ; Mon, 9 Dec 2013 03:03:08 -0800 (PST) Received: from statler.isode.com (statler.isode.com [62.3.217.254]) by ietfa.amsl.com (Postfix) with ESMTP id 5B5AD1AE255 for ; Mon, 9 Dec 2013 03:03:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1386586983; d=isode.com; s=selector; i=@isode.com; bh=q9HgLD3IEaCANHcFUg157Ef0ugDff4TlfAAdr7cfNWI=; 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=seAucwHHz5OWdBrU+lClvqkXBznrOUEjBUucB1YKZ2fQGvoJmMPbuNQubesGGAj72hPzPB nR8PH270bhaLmf1NZzgFPoHkzkggCKwWjmA8CxEqoPboL4/usB0CLsMfJ10ZRkA4MZsosH 1RA1V+vh3y2H/rCm8eSBlteeZDkR73c=; Received: from [172.17.128.75] (richard.isode.com [62.3.217.249]) by statler.isode.com (submission channel) via TCP with ESMTPSA id ; Mon, 9 Dec 2013 11:03:03 +0000 X-SMTP-Protocol-Errors: PIPELINING Message-ID: <52A5A366.1080609@isode.com> Date: Mon, 09 Dec 2013 11:03:02 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 To: Bron Gondwana References: <1386287986.3881.56114933.3A3FC70D@webmail.messagingengine.com> In-Reply-To: <1386287986.3881.56114933.3A3FC70D@webmail.messagingengine.com> 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] WGLC on QRESYNC, Ending 6th December. X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Dec 2013 11:03:10 -0000 Hi Bron, Thank you for your comments. On 05/12/2013 23:59, Bron Gondwana wrote: > I'm sorry I haven't taken the time to do a really thorough reading of > the latest draft earlier! > I've noted a couple of spots that I should double-check the Cyrus > implementation. > I notice that METADATA/ANNOTATE-EXPERIMENT-1 aren't addressed at all. > That certainly makes things simpler, but for those of us who _do_ > implement it... I'm just treating it exactly like like flags - any > change to anything updates the entire message MODSEQ. We're not > keeping separate MODSEQ values on annotations (yet). There seem to be an emerging consensus that a mailbox metadata change should update mailbox's HIGHESTMODSEQ (ANNOTATE-EXPERIMENT-1 is already covered, at least that was the intent), so I will do this change to the document. [I will reply to the rest of your review separately] From dave@cridland.net Mon Dec 9 03:07:56 2013 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B04C1AE27C for ; Mon, 9 Dec 2013 03:07:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6NvAgl2QqhNc for ; Mon, 9 Dec 2013 03:07:55 -0800 (PST) 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 651A51ADDD0 for ; Mon, 9 Dec 2013 03:07:55 -0800 (PST) Received: by mail-ob0-f176.google.com with SMTP id va2so3522673obc.21 for ; Mon, 09 Dec 2013 03:07:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cridland.net; s=google; h=mime-version:date:message-id:subject:from:to:content-type; bh=BfJ2NQ2WBlkw9qCserVv9cindg7dcFwqFeDvq+yOhXE=; b=dCDYBPs6cwMQDvjV2HVpuGjm9Qln67Erg2g8GZNJANxOB9q6RyTfUUugMb7mpqEgYn A/P6cPDoGgc2CsBTzTVKg7vDSKGSUsodj9s15BUu17etgO6Gt8B8D0lEnH7nFhyyF99b z4/8D0/Y1D0roWdTEq9tfqi0p7UxD7/UlClsw= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=BfJ2NQ2WBlkw9qCserVv9cindg7dcFwqFeDvq+yOhXE=; b=D6EJL9swDIPZyr0AALlgdjxyi42SoZQK44qHyHfuEJrp1BGwnpZYax5Lw4RQYgaE7M 5PYS1/stComDKf123Ug2dFWZjZVIKc+PZ9+SSVD+erOLxMcqZnqmvRII0qo3WqxMFVVm SasrptxD4+jx7ZIY4vqw1LZxeNzn5Au2KLQ+lm/9h6KmJ85bzVckr2kQwdW01ElgLezh 9EEq5V+2v4FCIgGWfR1P1rsj6jHcyWjEAwDsAx3e23g+dMb7CKuFL9BJMS42hdAWOVca ClacaVUn1ns7PjQ4kXEeRsvj1lZ9w+v7v/A4zd9sby2HAaVl6b+mhJuEmhSKzIpExU/y gqvQ== X-Gm-Message-State: ALoCoQkYZZEkUG5rQyDBGMc1a4+vzSUjA1FUYWJ7virQEe+MAhyVJG7hCRTxjBb1vO7aaAN4P1ta MIME-Version: 1.0 X-Received: by 10.182.113.195 with SMTP id ja3mr2162792obb.46.1386587270403; Mon, 09 Dec 2013 03:07:50 -0800 (PST) Received: by 10.60.144.38 with HTTP; Mon, 9 Dec 2013 03:07:50 -0800 (PST) Date: Mon, 9 Dec 2013 11:07:50 +0000 Message-ID: From: Dave Cridland To: "imapext@ietf.org" Content-Type: multipart/alternative; boundary=089e013d0db0b49da304ed180186 Subject: [imapext] WGLC on QRESYNC, Ended 6th December X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Dec 2013 11:07:56 -0000 --089e013d0db0b49da304ed180186 Content-Type: text/plain; charset=ISO-8859-1 Folks, The working group last call period for draft-ietf-qresync-rfc5162bis-03.txt has now ended. If you're in the process of a detailed review (ie, you're expecting to make some late comments), please let us know. I'm going to go through and catalogue the issues raised now. Dave. --089e013d0db0b49da304ed180186 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Folks,

The working group last call peri= od for draft-ietf-qresync-rfc5162bis-03.txt has now ended.

If you're in the process of a detailed review (ie, you're = expecting to make some late comments), please let us know.

I'm going to go through and catalogue the issues ra= ised now.

Dave.
--089e013d0db0b49da304ed180186-- From alexey.melnikov@isode.com Mon Dec 9 03:33:39 2013 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 498F81AE26D for ; Mon, 9 Dec 2013 03:33:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.702 X-Spam-Level: X-Spam-Status: No, score=-1.702 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v0EY0015zQ39 for ; Mon, 9 Dec 2013 03:33:38 -0800 (PST) Received: from statler.isode.com (statler.isode.com [62.3.217.254]) by ietfa.amsl.com (Postfix) with ESMTP id EAD431ADF5E for ; Mon, 9 Dec 2013 03:33:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1386588810; d=isode.com; s=selector; i=@isode.com; bh=PdDYdZ0XJXFBhED4+qHEev3G2O7tg8klyJfSLE5z0x8=; 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=Z28cNH0rKjFSfay0u5d6HNaSlwkwbTVgbE1ydqsAhokBhamY/X/Pli0VaEL6K5r9OmdHX3 YJ7bZsozHbu4lcYug+bPdkNYtNqbCRKux8rvdp0G72tQQsiJ6Uhwdh2MY/1439UPUR9/qm nwOSfmpos3RRFIg00jMJWmdTp2Vardw=; Received: from [172.17.128.75] (richard.isode.com [62.3.217.249]) by statler.isode.com (submission channel) via TCP with ESMTPSA id ; Mon, 9 Dec 2013 11:33:30 +0000 X-SMTP-Protocol-Errors: PIPELINING Message-ID: <52A5AA87.4020707@isode.com> Date: Mon, 09 Dec 2013 11:33:27 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 To: =?ISO-8859-1?Q?Jan_Kundr=E1t?= References: <20131008141122.25649.73956.idtracker@ietfa.amsl.com> <368e22b4-930e-4882-bca4-8b23bc3d4b06@flaska.net> <5293A4FF.6030406@isode.com> <08f2fdeb-957f-4ed4-a827-bdce2094275f@flaska.net> In-Reply-To: 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] I-D Action: draft-ietf-qresync-rfc5162bis-03.txt X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Dec 2013 11:33:39 -0000 Hi Jan, On 03/12/2013 10:45, Jan Kundr=E1t wrote: > So, with the WG last call deadline approaching, I would appreciate=20 > some sort of feedback on the points I raised. > > The so far unaddressed issues are: > > - Some corner cases are not well-defined when it comes to VANISHED=20 > reporting of messages which were just made available to the client via=20 > EXISTS. > > - Relation with METADATA and ANNOTATE-EXPERIMENT-1. What I would like=20 > to see here is explicit confirmation that any change in METADATA=20 > increments the HIGHESTMODSEQ Yes, I just added this to the document. > and that the data tracked by ANNOTATE-EXPERIMENT-1 are in fact=20 > "metadata" to be included in the MODSEQ tracking. Ok, I clarified this in my copy. Best Regards, Alexey From alexey.melnikov@isode.com Mon Dec 9 03:44:40 2013 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FDDB1AD72A for ; Mon, 9 Dec 2013 03:44:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5fXkUsGpdM-W for ; Mon, 9 Dec 2013 03:44:38 -0800 (PST) Received: from statler.isode.com (statler.isode.com [62.3.217.254]) by ietfa.amsl.com (Postfix) with ESMTP id 2A55F1ADE71 for ; Mon, 9 Dec 2013 03:44:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1386589472; d=isode.com; s=selector; i=@isode.com; bh=PHiSu3+4Rw79Q8O1Df8eBHJbUSmaecISNkvRAI2WGUQ=; 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=tdGSbHwpNoxf4rQtWRNUQPNEdGyzroODNNpLVOn8WfQiak6WXl3B0EVOI+1QvwIKjt3NKq +XyFUpxj1a/XJLmI/2C9Jmc2z2bHrJv2rD4guM3hkoGE3cnA2TUOW0fKoWfahS5oNkCSx+ xK+vbDvQygXAc4Knl8CJ5dgSXtzvyzM=; Received: from [172.17.128.75] (richard.isode.com [62.3.217.249]) by statler.isode.com (submission channel) via TCP with ESMTPSA id ; Mon, 9 Dec 2013 11:44:32 +0000 X-SMTP-Protocol-Errors: PIPELINING Message-ID: <52A5AD1D.9070103@isode.com> Date: Mon, 09 Dec 2013 11:44:29 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 To: Michael M Slusarz References: <20131008141122.25649.73956.idtracker@ietfa.amsl.com> <20131206171614.Horde.I3inQX4SvzGsmVDXyHl8fg9@bigworm.curecanti.org> In-Reply-To: <20131206171614.Horde.I3inQX4SvzGsmVDXyHl8fg9@bigworm.curecanti.org> 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-03.txt X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Dec 2013 11:44:40 -0000 Hi Michael, Thank you for your detailed comments. On 07/12/2013 00:16, Michael M Slusarz wrote: > Last minute suggestions, mostly editorial: > > * Abstract: The first two paragraphs are a lengthy description on > CONDSTORE behavior with respect to multiple IMAP clients > accessing/altering a common mailbox (a "protected update mechanism"). > That seems to be a rarer use-case; the majority of IMAP users are > using a single client to access personal mailboxes vs. the more > specialized use of a "message queue". > > To me, the more important real-world usage of CONDSTORE is the ability > to quickly and accurately sync flag changes and/or the more general > ability to accurately determine if a mailbox has been altered via > HIGHESTMODSEQ. I suggest this should be mentioned first instead of > second. Yes, I was already thinking about this. At minimum I want to swap the order. I haven't done this change in my copy of the document yet, but it is pending. > * Regarding HIGHESTMODSEQ/NOMODSEQ: the document uses the language > "the OK untagged response". That can be a bit confusing when reading > since it can be interpreted as SELECT/EXAMINE only containing a single > untagged OK response. > > Understood that someone needs to be familiar with 3501 before being > able to interpret this document, but wondering if the phrase "an OK > untagged response" should be used instead. To me, this more clearly > indicates that HIGHESTMODSEQ/NOMODSEQ needs to appear in one of the > (possibly multiple) OK responses. Good point, changed. > * All examples referring to MODSEQs: The examples can be a bit hard to > visually parse given large MODSEQ numbers, since it is not readily > apparent the relationship between the various MODSEQ values. > > Example 3: > > C: a103 UID STORE 6,4,8 (UNCHANGEDSINCE 12121230045) > +FLAGS.SILENT (\Deleted) > S: * 1 FETCH (UID 4 MODSEQ (12121231000)) > S: * 2 FETCH (UID 6 MODSEQ (12121230852)) > S: * 4 FETCH (UID 8 MODSEQ (12121130956)) > S: a103 OK Conditional Store completed > > In this example, the '1212123' prefix is noise that makes it difficult > to determine the relationship between the significant digits in the > MODSEQs. On first glance, it is not easy to see that 12121230852 > > 12121230045. > > To me, at least, simpler MODSEQs make for an easier understanding that > all UIDs specified in the STORE command were in fact changed: > > C: a103 UID STORE 6,4,8 (UNCHANGEDSINCE 5) > +FLAGS.SILENT (\Deleted) > S: * 1 FETCH (UID 4 MODSEQ (6)) > S: * 2 FETCH (UID 6 MODSEQ (7)) > S: * 4 FETCH (UID 8 MODSEQ (8)) > S: a103 OK Conditional Store completed I am a bit worried about introducing bugs by a change like this (I've done that in the past). So I would like to hear what other people think about this? [...] > * Section 3.2.2 typo: "REQUIREd" should be "REQUIRED". Fixed, thanks. > * Section 3.2.5: Document indicates BAD tagged response should be > issued if VANISHED UID FETCH modifier is either used with a FETCH > command or if ENABLE QRESYNC has not been issued. > > For completeness, this should also be made clear for the instance > where the VANISHED modifier is either used without CHANGEDSINCE -or- > an additional UID FETCH modifier is used: > > The VANISHED UID FETCH modifier MUST only be specified together with > the CHANGEDSINCE UID FETCH modifier. If the VANISHED UID FETCH > modifier > is used without the CHANGEDSINCE UID FETCH modifier, or if additional > UID FETCH modifiers besides CHANGEDSINCE and VANISHED are used, the > server MUST respond with a tagged BAD response. I don't think we can have restriction on other future FETCH modifiers. So I am Ok with your text if "or if additional UID FETCH modifiers besides CHANGEDSINCE and VANISHED are used" is dropped from it. Does this sound reasonable? Best Regards, Alexey From alexey.melnikov@isode.com Mon Dec 9 03:47:50 2013 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 723C21ADF44 for ; Mon, 9 Dec 2013 03:47:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8KQK0tFfKYqS for ; Mon, 9 Dec 2013 03:47:49 -0800 (PST) Received: from statler.isode.com (statler.isode.com [62.3.217.254]) by ietfa.amsl.com (Postfix) with ESMTP id 008C61AD72A for ; Mon, 9 Dec 2013 03:47:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1386589663; d=isode.com; s=selector; i=@isode.com; bh=N3tXYs1I5rL4FL21BblHiNenhwjqY5e4ETyrASqSL7o=; 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=cqsAnqTWqo62QwS0RD7+nnJbN6pY+ALm3/VnS3RCn2DxRyXE+hDIss3e2CSdIp6O+ExeNW p+X7jjXor6wz1zzgyA085fDyKR0WjnnQhdXUetHoCzVASNvg+jB40vIgj8n5ULjdIyyrKv SczWBVBxrqqc6psSey5HpvjkZ0n7Z50=; Received: from [172.17.128.75] (richard.isode.com [62.3.217.249]) by statler.isode.com (submission channel) via TCP with ESMTPSA id ; Mon, 9 Dec 2013 11:47:43 +0000 X-SMTP-Protocol-Errors: PIPELINING Message-ID: <52A5ADDE.6070308@isode.com> Date: Mon, 09 Dec 2013 11:47:42 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 To: Michael M Slusarz References: <20131008141122.25649.73956.idtracker@ietfa.amsl.com> <20131206171614.Horde.I3inQX4SvzGsmVDXyHl8fg9@bigworm.curecanti.org> In-Reply-To: <20131206171614.Horde.I3inQX4SvzGsmVDXyHl8fg9@bigworm.curecanti.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: imapext@ietf.org Subject: [imapext] Should CONDSTORE require automatic use of UID FETCH data items in responses? (was I-D Action: draft-ietf-qresync-rfc5162bis-03.txt) X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Dec 2013 11:47:50 -0000 Hi Michael, Answering to your remaining comment in a separate message. On 07/12/2013 00:16, Michael M Slusarz wrote: > * UID information in FETCH responses is only required if QRESYNC is > enabled (3.2.3). However, the only examples of what happens when an > external agent triggers an unsolicited FETCH response appear in the > CONDSTORE section, and it doesn't include UID information. E.g., from > Page 17: > > C: C360 NOOP > S: * 7 FETCH (FLAGS (\Deleted) MODSEQ (12121245160)) > S: C360 OK Noop completed > > While discussing QRESYNC prospectively within the CONDSTORE definition > might be a bit confusing, it is also the logical place to do so given > the current examples. At least a mention might be made to 3.2.3: > 'Note that this FETCH response MUST include UID data if both a > "CONDSTORE enabling command" has been issued and QRESYNC is supported > by the server'. Hmm, this brings an interesting question: should the requirement to return UIDs also apply to CONDSTORE? Best Regards, Alexey From adrien@qbik.com Mon Dec 9 04:05:34 2013 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4A0C1ADF57 for ; Mon, 9 Dec 2013 04:05:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8sH91n-BuTfY for ; Mon, 9 Dec 2013 04:05:33 -0800 (PST) Received: from smtp.qbik.com (smtp.qbik.com [210.55.214.35]) by ietfa.amsl.com (Postfix) with ESMTP id B0E071ADF5D for ; Mon, 9 Dec 2013 04:05:32 -0800 (PST) Received: From [192.168.0.23] (unverified [192.168.0.23]) by SMTP Server [192.168.0.1] (WinGate SMTP Receiver v8.0.6 (Build 4637)) with SMTP id <0019912827@smtp.qbik.com>; Tue, 10 Dec 2013 01:05:43 +1300 From: "Adrien de Croy" To: "Alexey Melnikov" , "Michael M Slusarz" Date: Mon, 09 Dec 2013 12:05:43 +0000 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; format=flowed; charset=utf-8 In-Reply-To: <52A5AD1D.9070103@isode.com> Message-Id: Mime-Version: 1.0 User-Agent: eM_Client/5.0.19406.0 Cc: "imapext@ietf.org" Subject: Re: [imapext] I-D Action: draft-ietf-qresync-rfc5162bis-03.txt X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Adrien de Croy List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Dec 2013 12:05:35 -0000 ------ Original Message ------ From: "Alexey Melnikov" > >On 07/12/2013 00:16, Michael M Slusarz wrote: >>* All examples referring to MODSEQs: The examples can be a bit hard to= =20 >>visually parse given large MODSEQ numbers, since it is not readily=20 >>apparent the relationship between the various MODSEQ values. >> >>Example 3: >> >> C: a103 UID STORE 6,4,8 (UNCHANGEDSINCE 12121230045) >> +FLAGS.SILENT (\Deleted) >> S: * 1 FETCH (UID 4 MODSEQ (12121231000)) >> S: * 2 FETCH (UID 6 MODSEQ (12121230852)) >> S: * 4 FETCH (UID 8 MODSEQ (12121130956)) >> S: a103 OK Conditional Store completed >> >>In this example, the '1212123' prefix is noise that makes it difficult= =20 >>to determine the relationship between the significant digits in the=20 >>MODSEQs. On first glance, it is not easy to see that 12121230852 >=20 >>12121230045. >> >>To me, at least, simpler MODSEQs make for an easier understanding that= =20 >>all UIDs specified in the STORE command were in fact changed: >> >> C: a103 UID STORE 6,4,8 (UNCHANGEDSINCE 5) >> +FLAGS.SILENT (\Deleted) >> S: * 1 FETCH (UID 4 MODSEQ (6)) >> S: * 2 FETCH (UID 6 MODSEQ (7)) >> S: * 4 FETCH (UID 8 MODSEQ (8)) >> S: a103 OK Conditional Store completed >I am a bit worried about introducing bugs by a change like this (I've=20 >done that in the past). So I would like to hear what other people think= =20 >about this? I agree with Michael. When I first saw the very long UIDs, I found it hard to compare them. =20 This made it more effort to see what was going on. There's also more=20 chance of a typo, as in the UID for #4 (12121130956 should read=20 12121230956), which makes the example incorrect. Cheers Adrien From alexey.melnikov@isode.com Mon Dec 9 04:07:26 2013 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 569011ADDD1 for ; Mon, 9 Dec 2013 04:07:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.702 X-Spam-Level: X-Spam-Status: No, score=-1.702 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GPQWwI-mz_HU for ; Mon, 9 Dec 2013 04:07:24 -0800 (PST) Received: from statler.isode.com (statler.isode.com [62.3.217.254]) by ietfa.amsl.com (Postfix) with ESMTP id A04DC1ADF66 for ; Mon, 9 Dec 2013 04:07:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1386590838; d=isode.com; s=selector; i=@isode.com; bh=WGpeUFaxiW14sBODLVyR5DeHeOq7oEVwKZwWbaKqbsY=; 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=Ff90kR8/sYmZX6oF94TLI2P3k8QM1XeIhyEcv1RvPeniw0h/ikLiZZ75xmh27sD5xmesIK O7wHrjfjLjo6lGEgwFeNDSflMlJvL71hH7pi2rK5S7b//RdTh1FPeQ5Nv8gUNBV4rqs9VJ Cc2UHf88L2A3GUospLcWBsRKj6azkM8=; Received: from [172.17.128.75] (richard.isode.com [62.3.217.249]) by statler.isode.com (submission channel) via TCP with ESMTPSA id ; Mon, 9 Dec 2013 12:07:18 +0000 X-SMTP-Protocol-Errors: PIPELINING Message-ID: <52A5B275.5060702@isode.com> Date: Mon, 09 Dec 2013 12:07:17 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 To: =?UTF-8?B?SmFuIEt1bmRyw6F0?= References: <420444CE-45E0-413C-ADB7-1414EEDF6A42@iki.fi> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-transfer-encoding: quoted-printable Cc: imapext@ietf.org Subject: Re: [imapext] I-D Action: draft-ietf-qresync-rfc5162bis-03.txt X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Dec 2013 12:07:26 -0000 Hi Jan, On 03/12/2013 23:00, Jan Kundr=C3=A1t wrote: > On Tuesday, 3 December 2013 21:08:06 CEST, Timo Sirainen wrote: >> So Jan isn=E2=80=99t talking about keeping track of which FETCH UID repli= es=20 >> have been sent to client, that would be extra trouble. > > Thanks, that's exactly what I meant. You are right that talking about=20 > messages is clearer than mudding the waters with UIDs -- sorry for=20 > this confusion. > > What about this, then: > > Note that a VANISHED response without the EARLIER tag (i.e. > a VANISHED response caused by EXPUNGE, UID EXPUNGE, or messages > expunged in other connections) MUST only refer to a message > which was visible to the client at the time VANISHED is sent. > That is, servers MUST NOT send send UIDs for previously expunged > messages, or messages which were not announced to the client via > EXISTS. This means that each UID listed in a VANISHED response > results in the client decrementing the message count by one. This > is required to prevent a possible race condition where new arrivals > for which the UID is not yet known by the client are immediately > expunged. Ok, I like this text. This was always the intent and this is what my=20 client assumes. > For example, if the mailbox contained UIDs 2 and 4, each of the > following responses would consitute a broken server implementation: > > * VANISHED 1 > * VANISHED 3 > * VANISHED 5 > > I have the impression that splitting the VANISHED response into=20 > VANISHED and VANISHED EARLIER would make sense. These are very=20 > different from a client's point of view. If the XML source of the RFC=20 > is available, I'm volunteering to make this happen. https://github.com/aamelnikov/draft-rfc4551-bis But wait till I post a new version (should be later today). From brong@fastmail.fm Mon Dec 9 04:17:29 2013 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A167E1ADF51 for ; Mon, 9 Dec 2013 04:17:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IqR1kXxGXQQN for ; Mon, 9 Dec 2013 04:17:27 -0800 (PST) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) by ietfa.amsl.com (Postfix) with ESMTP id 959781ADBD5 for ; Mon, 9 Dec 2013 04:17:27 -0800 (PST) Received: from compute5.internal (compute5.nyi.mail.srv.osa [10.202.2.45]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id 073F22099B for ; Mon, 9 Dec 2013 07:17:22 -0500 (EST) Received: from web6 ([10.202.2.216]) by compute5.internal (MEProxy); Mon, 09 Dec 2013 07:17:22 -0500 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= a6pUo2JGaav8nuPo2mtny7deykg=; b=fcXwXKZt5n9Ja2g4WJj6ersvZ/aF4lBb Laixz9q89nq4O68lWiwNLzKvAjpRPPAnsCOZJ40LxRfPYXdfRymUu7jr43vA8Q/M 2x/olGa96dLypGQHw3XQGL3yaHUBcRNS1ePRbWqs79b1w9Q04S3dlYQ9xAaH2TpO l7odS3wcrUE= 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=a6pUo2JGaav8nuPo2mtny7deykg=; b=bAYea hQyJmK4+XUvwRstEmd9d0w2C6Ue9zedWdG2+qDLXZKi8apwmiCWKhWC+eUoXJqLF Q7aQpH1sDJ/8jwRJCsKg+w/Jeue8BAI2n57wDggnbJrrmIIxEpUaX4+lcwDSdOAr 6/7YpsioxfXzPBI+FFsEy609n1e8XmW5+WXC0U= Received: by web6.nyi.mail.srv.osa (Postfix, from userid 99) id E374C29476C; Mon, 9 Dec 2013 07:17:21 -0500 (EST) Message-Id: <1386591441.1524.57290317.6E0F3C3F@webmail.messagingengine.com> X-Sasl-Enc: 64ZXr9Z7f4Xv7hoJxmp8EPyBBou+guAXQvMyx5kEuN9r 1386591441 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-e304fd37 Date: Mon, 09 Dec 2013 23:17:21 +1100 In-Reply-To: <52A5ADDE.6070308@isode.com> References: <20131008141122.25649.73956.idtracker@ietfa.amsl.com> <20131206171614.Horde.I3inQX4SvzGsmVDXyHl8fg9@bigworm.curecanti.org> <52A5ADDE.6070308@isode.com> Subject: Re: [imapext] Should CONDSTORE require automatic use of UID FETCH data items in responses? (was I-D Action: draft-ietf-qresync-rfc5162bis-03.txt) X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Dec 2013 12:17:29 -0000 On Mon, Dec 9, 2013, at 10:47 PM, Alexey Melnikov wrote: > Hi Michael, > Answering to your remaining comment in a separate message. > > On 07/12/2013 00:16, Michael M Slusarz wrote: > > > * UID information in FETCH responses is only required if QRESYNC is > > enabled (3.2.3). However, the only examples of what happens when an > > external agent triggers an unsolicited FETCH response appear in the > > CONDSTORE section, and it doesn't include UID information. E.g., from > > Page 17: > > > > C: C360 NOOP > > S: * 7 FETCH (FLAGS (\Deleted) MODSEQ (12121245160)) > > S: C360 OK Noop completed > > > > While discussing QRESYNC prospectively within the CONDSTORE definition > > might be a bit confusing, it is also the logical place to do so given > > the current examples. At least a mention might be made to 3.2.3: > > 'Note that this FETCH response MUST include UID data if both a > > "CONDSTORE enabling command" has been issued and QRESYNC is supported > > by the server'. > Hmm, this brings an interesting question: should the requirement to > return UIDs also apply to CONDSTORE? I would vote yes - CONDSTORE enabling command means UIDs in everything. It's very unlikely to break any existing clients. Bron. -- Bron Gondwana brong@fastmail.fm From alexey.melnikov@isode.com Mon Dec 9 04:21:14 2013 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E65D1AE1DA for ; Mon, 9 Dec 2013 04:21:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id INDI6tm4DgLh for ; Mon, 9 Dec 2013 04:21:12 -0800 (PST) Received: from statler.isode.com (statler.isode.com [62.3.217.254]) by ietfa.amsl.com (Postfix) with ESMTP id A2EA91AE227 for ; Mon, 9 Dec 2013 04:21:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1386591666; d=isode.com; s=selector; i=@isode.com; bh=ydlfGEJNADWMpsBOro3JD2aesisIlh4l7GKUJoyTA6U=; 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=xJxtp+F6GNy84jTsAyOO7/f8qbdu0tqFTdNARCEt6pkmqcx4pJVvwN/Gt7JZpyAUtzcmUR Qnd1E0O5/M98K3+OzL092dq3Un2BMNp9C4UDYPqYj3jrb/wTM6aM01ElKfOlQiUsqt8XNE /JrtRBxMpalzc4vjn2hLlyicZ+YGXoQ=; Received: from [172.17.128.75] (richard.isode.com [62.3.217.249]) by statler.isode.com (submission channel) via TCP with ESMTPSA id ; Mon, 9 Dec 2013 12:21:06 +0000 X-SMTP-Protocol-Errors: PIPELINING Message-ID: <52A5B5B1.50309@isode.com> Date: Mon, 09 Dec 2013 12:21:05 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 To: Michael M Slusarz References: <20131008141122.25649.73956.idtracker@ietfa.amsl.com> <20131206171614.Horde.I3inQX4SvzGsmVDXyHl8fg9@bigworm.curecanti.org> <20131206175620.Horde.ix0PtAsRkTI_thz72gWfaQ1@bigworm.curecanti.org> In-Reply-To: <20131206175620.Horde.ix0PtAsRkTI_thz72gWfaQ1@bigworm.curecanti.org> 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-03.txt X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Dec 2013 12:21:14 -0000 On 07/12/2013 00:56, Michael M Slusarz wrote: > Quoting Michael M Slusarz : > >> Example 3: >> >> C: a103 UID STORE 6,4,8 (UNCHANGEDSINCE 12121230045) >> +FLAGS.SILENT (\Deleted) >> S: * 1 FETCH (UID 4 MODSEQ (12121231000)) >> S: * 2 FETCH (UID 6 MODSEQ (12121230852)) >> S: * 4 FETCH (UID 8 MODSEQ (12121130956)) >> S: a103 OK Conditional Store completed > > On further review: isn't this example wrong? Why is UID 8 returned? > It has a MODSEQ lower than the UNCHANGEDSINCE value, so it didn't fail > the UNCHANGEDSINCE test. Therefore, it must have already had the > \Deleted flag set. Since .SILENT was specified, only the messages > that had flag data altered should be returned in FETCH untagged > responses (UIDs 4,6). > > The correct example should be: > > C: a103 UID STORE 6,4,8 (UNCHANGEDSINCE 12121230045) > +FLAGS.SILENT (\Deleted) > S: * 1 FETCH (UID 4 MODSEQ (12121231000)) > S: * 2 FETCH (UID 6 MODSEQ (12121230852)) > S: a103 OK Conditional Store completed > > Or maybe this was intended: > > C: a103 UID STORE 6,4,8 (UNCHANGEDSINCE 12121230045) > +FLAGS.SILENT (\Deleted) > S: * 1 FETCH (UID 4 MODSEQ (12121231000)) > S: * 2 FETCH (UID 6 MODSEQ (12121230852)) > S: * 4 FETCH (UID 8 MODSEQ (12121230956)) > S: a103 OK Conditional Store completed > > (i.e. MODSEQ 12121*2*30956 instead of 12121*1*30956. This is a good > example of why simpler MODSEQ examples might be preferable). Good catch. I've fixed the example for now. From internet-drafts@ietf.org Mon Dec 9 04:28:23 2013 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73D401AE268; Mon, 9 Dec 2013 04:28:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vhv9ZQ5uiiO4; Mon, 9 Dec 2013 04:28:21 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 724551ADF6E; Mon, 9 Dec 2013 04:28:21 -0800 (PST) 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.83.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131209122821.2167.50656.idtracker@ietfa.amsl.com> Date: Mon, 09 Dec 2013 04:28:21 -0800 Cc: imapext@ietf.org Subject: [imapext] I-D Action: draft-ietf-qresync-rfc5162bis-04.txt X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.15 List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Dec 2013 12:28:23 -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 Extensions for Conditional STORE Operation or Quick= Flag Changes Resynchronization (CONDSTORE) and Quick Mailbox Resynchroniza= tion (QRESYNC) Author(s) : Alexey Melnikov Dave Cridland Filename : draft-ietf-qresync-rfc5162bis-04.txt Pages : 47 Date : 2013-12-09 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 of the specific message being looked up) 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 additionally defines another IMAP 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-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-qresync-rfc5162bis-04 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 tss@iki.fi Mon Dec 9 04:28:29 2013 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41DDB1AE29A for ; Mon, 9 Dec 2013 04:28:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0LtirdGbRvOn for ; Mon, 9 Dec 2013 04:28:27 -0800 (PST) Received: from dovecot.org (dovecot.org [193.210.130.67]) by ietfa.amsl.com (Postfix) with ESMTP id 8B2781AE28E for ; Mon, 9 Dec 2013 04:28:26 -0800 (PST) Received: from [192.168.10.102] (cs181255018.pp.htv.fi [82.181.255.18]) by dovecot.org (Postfix) with ESMTP id D9F171AE876C for ; Mon, 9 Dec 2013 14:28:20 +0200 (EET) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) From: Timo Sirainen In-Reply-To: <1386591441.1524.57290317.6E0F3C3F@webmail.messagingengine.com> Date: Mon, 9 Dec 2013 14:28:22 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <44D2E502-427F-474B-A790-282733CB1B83@iki.fi> References: <20131008141122.25649.73956.idtracker@ietfa.amsl.com> <20131206171614.Horde.I3inQX4SvzGsmVDXyHl8fg9@bigworm.curecanti.org> <52A5ADDE.6070308@isode.com> <1386591441.1524.57290317.6E0F3C3F@webmail.messagingengine.com> To: imapext@ietf.org X-Mailer: Apple Mail (2.1822) Subject: Re: [imapext] Should CONDSTORE require automatic use of UID FETCH data items in responses? (was I-D Action: draft-ietf-qresync-rfc5162bis-03.txt) X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Dec 2013 12:28:29 -0000 On 9.12.2013, at 14.17, Bron Gondwana wrote: >>> * UID information in FETCH responses is only required if QRESYNC is=20= >>> enabled (3.2.3). However, the only examples of what happens when an=20= >>> external agent triggers an unsolicited FETCH response appear in the=20= >>> CONDSTORE section, and it doesn't include UID information. E.g., = from=20 >>> Page 17: >>>=20 >>> C: C360 NOOP >>> S: * 7 FETCH (FLAGS (\Deleted) MODSEQ (12121245160)) >>> S: C360 OK Noop completed >>>=20 >>> While discussing QRESYNC prospectively within the CONDSTORE = definition=20 >>> might be a bit confusing, it is also the logical place to do so = given=20 >>> the current examples. At least a mention might be made to 3.2.3:=20 >>> 'Note that this FETCH response MUST include UID data if both a=20 >>> "CONDSTORE enabling command" has been issued and QRESYNC is = supported=20 >>> by the server'. >> Hmm, this brings an interesting question: should the requirement to=20= >> return UIDs also apply to CONDSTORE? >=20 > I would vote yes - CONDSTORE enabling command means UIDs in = everything. >=20 > It's very unlikely to break any existing clients. It wouldn=92t hurt, but I=92m not sure if it would help much either. I = think I proposed this somewhere, but I can=92t find where. Or at least = not in errata. Anyway, I think the point was that with QRESYNC the = client wouldn=92t necessarily have to keep MSN <-> UID mapping, since it = gets VANISHED replies. With only CONDSTORE enabled the client would = still have to keep the mapping to handle EXPUNGE replies. From tss@iki.fi Mon Dec 9 04:30:38 2013 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11AD11AE268 for ; Mon, 9 Dec 2013 04:30:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iERkp7uQ0Tey for ; Mon, 9 Dec 2013 04:30:36 -0800 (PST) Received: from dovecot.org (dovecot.org [193.210.130.67]) by ietfa.amsl.com (Postfix) with ESMTP id 5F8751AE253 for ; Mon, 9 Dec 2013 04:30:36 -0800 (PST) Received: from [192.168.10.102] (cs181255018.pp.htv.fi [82.181.255.18]) by dovecot.org (Postfix) with ESMTP id 2A6601AE876C for ; Mon, 9 Dec 2013 14:30:31 +0200 (EET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) From: Timo Sirainen In-Reply-To: Date: Mon, 9 Dec 2013 14:30:33 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <88314AE8-0795-4912-8A9B-5BBA13525E4F@iki.fi> References: To: "imapext@ietf.org" X-Mailer: Apple Mail (2.1822) Subject: Re: [imapext] I-D Action: draft-ietf-qresync-rfc5162bis-03.txt X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Dec 2013 12:30:38 -0000 On 9.12.2013, at 14.05, Adrien de Croy wrote: >>> To me, at least, simpler MODSEQs make for an easier understanding = that all UIDs specified in the STORE command were in fact changed: >>>=20 >>> C: a103 UID STORE 6,4,8 (UNCHANGEDSINCE 5) >>> +FLAGS.SILENT (\Deleted) >>> S: * 1 FETCH (UID 4 MODSEQ (6)) >>> S: * 2 FETCH (UID 6 MODSEQ (7)) >>> S: * 4 FETCH (UID 8 MODSEQ (8)) >>> S: a103 OK Conditional Store completed >> I am a bit worried about introducing bugs by a change like this (I've = done that in the past). So I would like to hear what other people think = about this? > I agree with Michael. >=20 > When I first saw the very long UIDs, I found it hard to compare them. = This made it more effort to see what was going on. There's also more = chance of a typo, as in the UID for #4 (12121130956 should read = 12121230956), which makes the example incorrect. Then again if only short modseqs are shown everywhere, client = implementors are going to use 32bit ints for them.. From adrien@qbik.com Mon Dec 9 04:35:02 2013 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E5A01AE295 for ; Mon, 9 Dec 2013 04:35:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zSrKs7U_DwFL for ; Mon, 9 Dec 2013 04:35:00 -0800 (PST) Received: from smtp.qbik.com (smtp.qbik.com [210.55.214.35]) by ietfa.amsl.com (Postfix) with ESMTP id 0920D1AE291 for ; Mon, 9 Dec 2013 04:34:59 -0800 (PST) Received: From [192.168.0.23] (unverified [192.168.0.23]) by SMTP Server [192.168.0.1] (WinGate SMTP Receiver v8.0.6 (Build 4637)) with SMTP id <0019912859@smtp.qbik.com>; Tue, 10 Dec 2013 01:35:11 +1300 From: "Adrien de Croy" To: "Timo Sirainen" , "imapext@ietf.org" Date: Mon, 09 Dec 2013 12:35:11 +0000 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; format=flowed; charset=utf-8 In-Reply-To: <88314AE8-0795-4912-8A9B-5BBA13525E4F@iki.fi> Message-Id: Mime-Version: 1.0 User-Agent: eM_Client/5.0.19406.0 Subject: Re: [imapext] I-D Action: draft-ietf-qresync-rfc5162bis-03.txt X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Adrien de Croy List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Dec 2013 12:35:02 -0000 ------ Original Message ------ From: "Timo Sirainen" >On 9.12.2013, at 14.05, Adrien de Croy wrote: > >>>> To me, at least, simpler MODSEQs make for an easier understanding=20 >>>>that all UIDs specified in the STORE command were in fact changed: >>>> >>>> C: a103 UID STORE 6,4,8 (UNCHANGEDSINCE 5) >>>> +FLAGS.SILENT (\Deleted) >>>> S: * 1 FETCH (UID 4 MODSEQ (6)) >>>> S: * 2 FETCH (UID 6 MODSEQ (7)) >>>> S: * 4 FETCH (UID 8 MODSEQ (8)) >>>> S: a103 OK Conditional Store completed >>> I am a bit worried about introducing bugs by a change like this=20 >>>(I've done that in the past). So I would like to hear what other=20 >>>people think about this? >> I agree with Michael. >> >> When I first saw the very long UIDs, I found it hard to compare them.= =20 >>This made it more effort to see what was going on. There's also more=20 >>chance of a typo, as in the UID for #4 (12121130956 should read=20 >>12121230956), which makes the example incorrect. > >Then again if only short modseqs are shown everywhere, client=20 >implementors are going to use 32bit ints for them.. from memory I thought it was explicitly stated to use larger than 32=20 bits signed. Most ironic that message size is limited to 32 bits and mod seq isn't. =20 That one is a train coming the wrong way down the tunnel. > >_______________________________________________ >imapext mailing list >imapext@ietf.org >https://www.ietf.org/mailman/listinfo/imapext From tss@iki.fi Mon Dec 9 04:41:38 2013 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1F111ADF63 for ; Mon, 9 Dec 2013 04:41:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xdv9J1TajqM3 for ; Mon, 9 Dec 2013 04:41:37 -0800 (PST) Received: from dovecot.org (dovecot.org [193.210.130.67]) by ietfa.amsl.com (Postfix) with ESMTP id 1D89E1ADF24 for ; Mon, 9 Dec 2013 04:41:37 -0800 (PST) Received: from [192.168.10.102] (cs181255018.pp.htv.fi [82.181.255.18]) by dovecot.org (Postfix) with ESMTP id 9868E1AE876C; Mon, 9 Dec 2013 14:41:31 +0200 (EET) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) From: Timo Sirainen In-Reply-To: Date: Mon, 9 Dec 2013 14:41:33 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <24DCC09B-7F2E-4B83-AF06-5DCAA6126CA0@iki.fi> References: To: Adrien de Croy X-Mailer: Apple Mail (2.1822) Cc: "imapext@ietf.org" Subject: Re: [imapext] I-D Action: draft-ietf-qresync-rfc5162bis-03.txt X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Dec 2013 12:41:39 -0000 On 9.12.2013, at 14.35, Adrien de Croy wrote: > ------ Original Message ------ > From: "Timo Sirainen" >> On 9.12.2013, at 14.05, Adrien de Croy wrote: >>=20 >>>>> To me, at least, simpler MODSEQs make for an easier understanding = that all UIDs specified in the STORE command were in fact changed: >>>>>=20 >>>>> C: a103 UID STORE 6,4,8 (UNCHANGEDSINCE 5) >>>>> +FLAGS.SILENT (\Deleted) >>>>> S: * 1 FETCH (UID 4 MODSEQ (6)) >>>>> S: * 2 FETCH (UID 6 MODSEQ (7)) >>>>> S: * 4 FETCH (UID 8 MODSEQ (8)) >>>>> S: a103 OK Conditional Store completed >>>> I am a bit worried about introducing bugs by a change like this = (I've done that in the past). So I would like to hear what other people = think about this? >>> I agree with Michael. >>>=20 >>> When I first saw the very long UIDs, I found it hard to compare = them. This made it more effort to see what was going on. There's also = more chance of a typo, as in the UID for #4 (12121130956 should read = 12121230956), which makes the example incorrect. >>=20 >> Then again if only short modseqs are shown everywhere, client = implementors are going to use 32bit ints for them.. >=20 > from memory I thought it was explicitly stated to use larger than 32 = bits signed. Sure, but it=92s only mentioned twice in the document. Easy to forget = while implementing and only looking at examples with small modseq = numbers. 1-2 examples with large modseqs would be good I think. From alexey.melnikov@isode.com Mon Dec 9 04:42:48 2013 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0ECE1AE2AF for ; Mon, 9 Dec 2013 04:42:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SXH_QOJGwL2I for ; Mon, 9 Dec 2013 04:42:46 -0800 (PST) Received: from statler.isode.com (statler.isode.com [62.3.217.254]) by ietfa.amsl.com (Postfix) with ESMTP id 98FD61AE303 for ; Mon, 9 Dec 2013 04:42:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1386592919; d=isode.com; s=selector; i=@isode.com; bh=qxyCrp+tLcASrA7oT9ZlM9DS2pp8KcfxN0DLOlQjyec=; 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=fC2K7LI4WvD0uL6SnIqNfa7jPlHymfmB5ingEPupQaBCt0dR23tigB4kPPJLZ1ixgFmUHe 7d2SXr+kfgO1ADfFhQqVezCTiiHBjB+BBHvaO4xNsag+T2LD5WE+WuU9RAXQP4fCxxbY4y rVKOEZ+65c4LQ1I/plSaL7+6wxFhnfA=; Received: from [172.17.128.75] (richard.isode.com [62.3.217.249]) by statler.isode.com (submission channel) via TCP with ESMTPSA id ; Mon, 9 Dec 2013 12:41:59 +0000 X-SMTP-Protocol-Errors: PIPELINING Message-ID: <52A5BA96.7040500@isode.com> Date: Mon, 09 Dec 2013 12:41:58 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 To: imapext@ietf.org References: <20131209122821.2167.50656.idtracker@ietfa.amsl.com> In-Reply-To: <20131209122821.2167.50656.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-rfc5162bis-04.txt X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Dec 2013 12:42:48 -0000 On 09/12/2013 12:28, 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 Extensions for Conditional STORE Operation or Quick Flag Changes Resynchronization (CONDSTORE) and Quick Mailbox Resynchronization (QRESYNC) > Author(s) : Alexey Melnikov > Dave Cridland > Filename : draft-ietf-qresync-rfc5162bis-04.txt > Pages : 47 > Date : 2013-12-09 I haven't done any major changes to the Abstract or the Introduction sections and I haven't done all of the changes suggested on the mailing list. I will try to post -05 later this week. From arnt@gulbrandsen.priv.no Mon Dec 9 04:42:59 2013 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1090F1AE2A4 for ; Mon, 9 Dec 2013 04:42:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QYQT_q_heEoh for ; Mon, 9 Dec 2013 04:42:57 -0800 (PST) Received: from strange.aox.org (strange.aox.org [80.244.248.170]) by ietfa.amsl.com (Postfix) with ESMTP id 02FF01AE2AD for ; Mon, 9 Dec 2013 04:42:14 -0800 (PST) Received: from fri.gulbrandsen.priv.no (localhost [127.0.0.1]) by strange.aox.org (Postfix) with ESMTP id 666E3FA0013; Mon, 9 Dec 2013 12:42:08 +0000 (UTC) Received: from arnt@gulbrandsen.priv.no by fri.gulbrandsen.priv.no (Archiveopteryx 3.2.0) with esmtpsa id 1386592926-29127-29126/11/3; Mon, 9 Dec 2013 12:42:06 +0000 Date: Mon, 9 Dec 2013 13:42:13 +0100 From: Arnt Gulbrandsen To: imapext@ietf.org Message-Id: <20131209124209.GA1028@gulbrandsen.priv.no> References: <88314AE8-0795-4912-8A9B-5BBA13525E4F@iki.fi> Mime-Version: 1.0 Content-Type: text/plain In-Reply-To: <88314AE8-0795-4912-8A9B-5BBA13525E4F@iki.fi> User-Agent: Mutt/1.5.21 (2010-09-15) Content-Transfer-Encoding: quoted-printable Subject: Re: [imapext] I-D Action: draft-ietf-qresync-rfc5162bis-03.txt X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Dec 2013 12:42:59 -0000 On Mon, Dec 09, 2013 at 02:30:33PM +0200, Timo Sirainen wrote: > On 9.12.2013, at 14.05, Adrien de Croy wrote: > > When I first saw the very long UIDs, I found it hard to compare = them. This made it more effort to see what was going on. There's also = more chance of a typo, as in the UID for #4 (12121130956 should read = 12121230956), which makes the example incorrect. >=20 > Then again if only short modseqs are shown everywhere, client implement= ors are going to use 32bit ints for them.. I completely agree with Timo. It's easy to make them comparable at a glance, just make sure there's always a few digits more and the top digit increases. It's easy to tell that 38823478494237 > 22347894237. 64-bit numbers are nice, they give us range. (Did I say 64? Oh foo. I meant 63. Must be kind to the java clients.) Arnt From brong@fastmail.fm Mon Dec 9 19:22:13 2013 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF3EA1AE029 for ; Mon, 9 Dec 2013 19:22:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cD_qDFigPP_D for ; Mon, 9 Dec 2013 19:22:12 -0800 (PST) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) by ietfa.amsl.com (Postfix) with ESMTP id 1E4381AE13F for ; Mon, 9 Dec 2013 19:22:11 -0800 (PST) Received: from compute5.internal (compute5.nyi.mail.srv.osa [10.202.2.45]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id 585EA21154 for ; Mon, 9 Dec 2013 22:22:06 -0500 (EST) Received: from web2 ([10.202.2.212]) by compute5.internal (MEProxy); Mon, 09 Dec 2013 22:22:06 -0500 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= /lk/XR8VHOp+T82hLqKQXJt+d20=; b=k7A5D299tJPWDUF7r0iMNwTRtDU743Uu b3gOuC2iOnXsZ8khImVqF36ucC632BrQHBx9nqNJGoRSaHVjMCZrpKm0U59GaSls cAC36v5QeXLVzH4WbeWP1SpgqRt/GQrX7zYk8xIEGHCWP/ggetjb/PVBvvCmtqOS R1Y71/rxzv4= 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=/lk/XR8VHOp+T82hLqKQXJt+d20=; b=OX7 WiogPlSNH+V8bmApcFxt6cfAiv1cE/MReTE650XvMGB1WFLwMFULRNVwA6uFQgFn uJ+NXVcMpbiSVkd1IAxDt0P84dxItSqhSm6BphMxDdbHj6ZrBTJO7ZMmjOOd+rlx D4zVFRIQfJ18SRjPFOp0y1Sho3KW5rj62CMf9tuw= Received: by web2.nyi.mail.srv.osa (Postfix, from userid 99) id 37F785401AD; Mon, 9 Dec 2013 22:22:06 -0500 (EST) Message-Id: <1386645726.26378.57638805.379F37C0@webmail.messagingengine.com> X-Sasl-Enc: DVxvQAxVCEHBdEZExnGZFXxUFn1m0qizZXS5gFDZIsOh 1386645726 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-e304fd37 In-Reply-To: <20131209124209.GA1028@gulbrandsen.priv.no> References: <88314AE8-0795-4912-8A9B-5BBA13525E4F@iki.fi> <20131209124209.GA1028@gulbrandsen.priv.no> Date: Tue, 10 Dec 2013 14:22:06 +1100 Subject: Re: [imapext] I-D Action: draft-ietf-qresync-rfc5162bis-03.txt X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Dec 2013 03:22:14 -0000 On Mon, Dec 9, 2013, at 11:42 PM, Arnt Gulbrandsen wrote: > On Mon, Dec 09, 2013 at 02:30:33PM +0200, Timo Sirainen wrote: > > On 9.12.2013, at 14.05, Adrien de Croy wrote: > > > When I first saw the very long UIDs, I found it hard to compare them. This made it more effort to see what was going on. There's also more chance of a typo, as in the UID for #4 (12121130956 should read 12121230956), which makes the example incorrect. > > > > Then again if only short modseqs are shown everywhere, client implementors are going to use 32bit ints for them.. > > I completely agree with Timo. > > It's easy to make them comparable at a glance, just make sure there's > always a few digits more and the top digit increases. It's easy to > tell that 38823478494237 > 22347894237. > > 64-bit numbers are nice, they give us range. (Did I say 64? Oh foo. I > meant 63. Must be kind to the java clients.) It sure was nice in Cyrus switching to 64 bits for quota and ditching uquota_t in the process. 63 bits ought to be enough for anybody. Bron. -- Bron Gondwana brong@fastmail.fm From lear@cisco.com Tue Dec 10 05:14:31 2013 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4FC01AE069 for ; Tue, 10 Dec 2013 05:14:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.502 X-Spam-Level: X-Spam-Status: No, score=-9.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B3b_R1T-jxeQ for ; Tue, 10 Dec 2013 05:14:30 -0800 (PST) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) by ietfa.amsl.com (Postfix) with ESMTP id 081261AE02E for ; Tue, 10 Dec 2013 05:14:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1217; q=dns/txt; s=iport; t=1386681265; x=1387890865; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=1GiWbpWtZhkYg0eo2zMMOmlw/fSBTgkLqLkZnYj0LEI=; b=VXk++rtj7ZaxjTaSA1xoTgUUNUlAe9d/gmxjRMKVp+Uf1jiQACYBAh1a gS0BOEJ89bAHyveR35KtpuuLvYfLbDpYSE5TRXwiK5opmuN82OXdgRLWZ mltR37tbtiThElSJK7nGWJfbS27bIOyACLoQTSpIX4a/Xnr+blqcSTrU8 U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhMFANoSp1KQ/khM/2dsb2JhbABZgweECrYcgR0WdIIlAQEBBCNVEQsOCgICBRYLAgIJAwIBAgErGgYBDAYCAQEVh2mxGI9bF4EpjWOCa4FIA5gUkhODKjs X-IronPort-AV: E=Sophos;i="4.93,865,1378857600"; d="scan'208";a="1350634" Received: from ams-core-3.cisco.com ([144.254.72.76]) by aer-iport-2.cisco.com with ESMTP; 10 Dec 2013 13:14:24 +0000 Received: from mctiny.local ([10.61.167.107]) by ams-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id rBADEKPi013646 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 10 Dec 2013 13:14:20 GMT Message-ID: <52A713AC.6010206@cisco.com> Date: Tue, 10 Dec 2013 14:14:20 +0100 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: Timo Sirainen , "imapext@ietf.org" References: <88314AE8-0795-4912-8A9B-5BBA13525E4F@iki.fi> In-Reply-To: <88314AE8-0795-4912-8A9B-5BBA13525E4F@iki.fi> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [imapext] I-D Action: draft-ietf-qresync-rfc5162bis-03.txt X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Dec 2013 13:14:32 -0000 Hi, On 12/9/13 1:30 PM, Timo Sirainen wrote: > On 9.12.2013, at 14.05, Adrien de Croy wrote: > >>>> To me, at least, simpler MODSEQs make for an easier understanding that all UIDs specified in the STORE command were in fact changed: >>>> >>>> C: a103 UID STORE 6,4,8 (UNCHANGEDSINCE 5) >>>> +FLAGS.SILENT (\Deleted) >>>> S: * 1 FETCH (UID 4 MODSEQ (6)) >>>> S: * 2 FETCH (UID 6 MODSEQ (7)) >>>> S: * 4 FETCH (UID 8 MODSEQ (8)) >>>> S: a103 OK Conditional Store completed >>> I am a bit worried about introducing bugs by a change like this (I've done that in the past). So I would like to hear what other people think about this? >> I agree with Michael. >> >> When I first saw the very long UIDs, I found it hard to compare them. This made it more effort to see what was going on. There's also more chance of a typo, as in the UID for #4 (12121130956 should read 12121230956), which makes the example incorrect. > Then again if only short modseqs are shown everywhere, client implementors are going to use 32bit ints for them.. > Best to show a real life example that has been cut and pasted from log files. That gets rid of any introduced errors. Eliot From slusarz@horde.org Tue Dec 10 10:08:29 2013 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46C6E1AE142 for ; Tue, 10 Dec 2013 10:08:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.8 X-Spam-Level: X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XnN3ZtsnPSpB for ; Tue, 10 Dec 2013 10:08:28 -0800 (PST) Received: from qmta13.emeryville.ca.mail.comcast.net (qmta13.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:44:76:96:27:243]) by ietfa.amsl.com (Postfix) with ESMTP id 47C9D1AE010 for ; Tue, 10 Dec 2013 10:08:27 -0800 (PST) Received: from omta12.emeryville.ca.mail.comcast.net ([76.96.30.44]) by qmta13.emeryville.ca.mail.comcast.net with comcast id zr331m0030x6nqcADu8NW6; Tue, 10 Dec 2013 18:08:22 +0000 Received: from bigworm.curecanti.org ([71.229.167.0]) by omta12.emeryville.ca.mail.comcast.net with comcast id zu8L1m00b00qwSn8Yu8Mly; Tue, 10 Dec 2013 18:08:22 +0000 Received: from bigworm.curecanti.org (localhost.localdomain [IPv6:::1]) (Authenticated sender: slusarz) by bigworm.curecanti.org (Postfix) with ESMTPSA id E403468068 for ; Tue, 10 Dec 2013 11:07:49 -0700 (MST) Received: from ip-64-134-27-125.public.wayport.net (ip-64-134-27-125.public.wayport.net [64.134.27.125]) by bigworm.curecanti.org (Horde Framework) with HTTP; Tue, 10 Dec 2013 11:07:49 -0700 Date: Tue, 10 Dec 2013 11:07:49 -0700 Message-ID: <20131210110749.Horde.qMnG-aHZp0vYIXbu8aoUsg2@bigworm.curecanti.org> From: Michael M Slusarz To: imapext@ietf.org References: <20131008141122.25649.73956.idtracker@ietfa.amsl.com> <20131206171614.Horde.I3inQX4SvzGsmVDXyHl8fg9@bigworm.curecanti.org> <52A5AD1D.9070103@isode.com> In-Reply-To: <52A5AD1D.9070103@isode.com> User-Agent: Internet Messaging Program (IMP) H5 (6.2.0-git) Accept-Language: en X-Originating-IP: 64.134.27.125 X-Remote-Browser: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:25.0) Gecko/20100101 Firefox/25.0 Content-Type: text/plain; charset=UTF-8; format=flowed; DelSp=Yes MIME-Version: 1.0 Content-Disposition: inline DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1386698902; bh=8Uh6kyjE3weWzCu6oMqGHWHNGw9oZjs+9zDqzYhd8uY=; h=Received:Received:Received:Received:Date:Message-ID:From:To: Subject:Content-Type:MIME-Version; b=UPbHpudLh02gg5XaDtEU9QourSMseyg7qgHynA3Gv7Bbgrpt/jJgPqZc1TLbmVP2F LUS+Dv/GWLThuvYR0VFohbPjZqaG0GMCgnjmHedu51VhFomTW79f8EuMITqa+dNV/P Oe3iCI0RqbmHfqQSJ7b8wN+jcoOYEi6aBNQi+KgT4QbA7Wxqp0NoyndIY+r1djtwfE +/IjmKG8sLziVgFhn7GFqeMhu/1XWxeTaanxnUAiQqGkFlUeU5BYn5X4kvu0P/EzR8 UWyMjwgMfqNtLf6WtAKu1IwBtt79x7VZZ/meKYkdVW/YPibsT2UN5rWrawRYdaaF80 m5Oep09717owA== Subject: Re: [imapext] I-D Action: draft-ietf-qresync-rfc5162bis-03.txt X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Dec 2013 18:08:29 -0000 Quoting Alexey Melnikov : >> * Section 3.2.5: Document indicates BAD tagged response should be >> issued if VANISHED UID FETCH modifier is either used with a FETCH >> command or if ENABLE QRESYNC has not been issued. >> >> For completeness, this should also be made clear for the instance >> where the VANISHED modifier is either used without CHANGEDSINCE >> -or- an additional UID FETCH modifier is used: >> >> The VANISHED UID FETCH modifier MUST only be specified together with >> the CHANGEDSINCE UID FETCH modifier. If the VANISHED UID FETCH modifier >> is used without the CHANGEDSINCE UID FETCH modifier, or if additional >> UID FETCH modifiers besides CHANGEDSINCE and VANISHED are used, the >> server MUST respond with a tagged BAD response. > I don't think we can have restriction on other future FETCH > modifiers. So I am Ok with your text if "or if additional UID FETCH > modifiers besides CHANGEDSINCE and VANISHED are used" is dropped > from it. Does this sound reasonable? That sounds more correct. FWIW, I did a quick check of Cyrus and Dovecot when I wrote this and they both issue BAD responses. michael ___________________________________ Michael Slusarz [slusarz@horde.org] From slusarz@horde.org Tue Dec 10 10:12:16 2013 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15E781AE142 for ; Tue, 10 Dec 2013 10:12:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id clG03WmRPvfb for ; Tue, 10 Dec 2013 10:12:13 -0800 (PST) Received: from qmta02.emeryville.ca.mail.comcast.net (qmta02.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:43:76:96:30:24]) by ietfa.amsl.com (Postfix) with ESMTP id 86BB81AE010 for ; Tue, 10 Dec 2013 10:12:13 -0800 (PST) Received: from omta09.emeryville.ca.mail.comcast.net ([76.96.30.20]) by qmta02.emeryville.ca.mail.comcast.net with comcast id zqBh1m0030S2fkCA2uC8DE; Tue, 10 Dec 2013 18:12:08 +0000 Received: from bigworm.curecanti.org ([71.229.167.0]) by omta09.emeryville.ca.mail.comcast.net with comcast id zuC71m00C00qwSn8VuC7Na; Tue, 10 Dec 2013 18:12:08 +0000 Received: from bigworm.curecanti.org (localhost.localdomain [IPv6:::1]) (Authenticated sender: slusarz) by bigworm.curecanti.org (Postfix) with ESMTPSA id BA78A68068 for ; Tue, 10 Dec 2013 11:12:06 -0700 (MST) Received: from ip-64-134-27-125.public.wayport.net (ip-64-134-27-125.public.wayport.net [64.134.27.125]) by bigworm.curecanti.org (Horde Framework) with HTTP; Tue, 10 Dec 2013 11:12:06 -0700 Date: Tue, 10 Dec 2013 11:12:06 -0700 Message-ID: <20131210111206.Horde.ATxqj4coKETgf96gDMXf0w3@bigworm.curecanti.org> From: Michael M Slusarz To: imapext@ietf.org References: <88314AE8-0795-4912-8A9B-5BBA13525E4F@iki.fi> <20131209124209.GA1028@gulbrandsen.priv.no> In-Reply-To: <20131209124209.GA1028@gulbrandsen.priv.no> User-Agent: Internet Messaging Program (IMP) H5 (6.2.0-git) Accept-Language: en X-Originating-IP: 64.134.27.125 X-Remote-Browser: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:25.0) Gecko/20100101 Firefox/25.0 Content-Type: text/plain; charset=UTF-8; format=flowed; DelSp=Yes MIME-Version: 1.0 Content-Disposition: inline DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1386699128; bh=UXN72f7Cyj1RE9SNOa6btDHK9fPntYz2TLCdv9EdKac=; h=Received:Received:Received:Received:Date:Message-ID:From:To: Subject:Content-Type:MIME-Version; b=FiZJtNaKqTEyFJVeJ1pdlf//BlBBQfgq8VVnTQ5HKNW6lg7Ef5HO0a5KThotMhopR fVzQdItrTTzk3asqqPib6AWOafMwEu+7noB409YcACqdm5PYD428P3R0hmJBAvsbuK aN/Si2RFGEUJdsIblMh4k0A9ypxbCcIgm6EIFUFK90XnpDYRQ9tSx2Ie0zMXlF2C6t jy02O8VVmT2BgsJjwi/EoweMlFMCmezRrlVcmiE4tGGmQOnjAl3YxkwYaL4HCf730b 4g9dtKdqxZZkSWo7uXif3MMXQY/HKlxqwn8X/p+Jcv5meX7PlqdkpWVndHx4bBN8dg Yktw912KjE5WQ== Subject: Re: [imapext] I-D Action: draft-ietf-qresync-rfc5162bis-03.txt X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Dec 2013 18:12:16 -0000 Quoting Arnt Gulbrandsen : > On Mon, Dec 09, 2013 at 02:30:33PM +0200, Timo Sirainen wrote: >> On 9.12.2013, at 14.05, Adrien de Croy wrote: >> > When I first saw the very long UIDs, I found it hard to compare >> them. This made it more effort to see what was going on. There's >> also more chance of a typo, as in the UID for #4 (12121130956 >> should read 12121230956), which makes the example incorrect. >> >> Then again if only short modseqs are shown everywhere, client >> implementors are going to use 32bit ints for them.. > > I completely agree with Timo. > > It's easy to make them comparable at a glance, just make sure there's > always a few digits more and the top digit increases. It's easy to > tell that 38823478494237 > 22347894237. Maybe a combo of what Timo and Arnt suggest. Keep a couple of examples with longer modseqs, to ensure there are some non 32-bit examples, but for those examples format the long modsesq the way Arnt suggests to make it easier to distinguish them. michael ___________________________________ Michael Slusarz [slusarz@horde.org] From slusarz@horde.org Tue Dec 10 10:25:29 2013 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49BE71AE1F2 for ; Tue, 10 Dec 2013 10:25:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uCEx4Ma_9ZEU for ; Tue, 10 Dec 2013 10:25:27 -0800 (PST) Received: from qmta08.emeryville.ca.mail.comcast.net (qmta08.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:43:76:96:30:80]) by ietfa.amsl.com (Postfix) with ESMTP id 39D3C1AE1E1 for ; Tue, 10 Dec 2013 10:25:27 -0800 (PST) Received: from omta08.emeryville.ca.mail.comcast.net ([76.96.30.12]) by qmta08.emeryville.ca.mail.comcast.net with comcast id zrYY1m0030FhH24A8uRNJR; Tue, 10 Dec 2013 18:25:22 +0000 Received: from bigworm.curecanti.org ([71.229.167.0]) by omta08.emeryville.ca.mail.comcast.net with comcast id zuRL1m00E00qwSn8UuRMjy; Tue, 10 Dec 2013 18:25:21 +0000 Received: from bigworm.curecanti.org (localhost.localdomain [IPv6:::1]) (Authenticated sender: slusarz) by bigworm.curecanti.org (Postfix) with ESMTPSA id 5196C68068 for ; Tue, 10 Dec 2013 11:24:50 -0700 (MST) Received: from ip-64-134-27-125.public.wayport.net (ip-64-134-27-125.public.wayport.net [64.134.27.125]) by bigworm.curecanti.org (Horde Framework) with HTTP; Tue, 10 Dec 2013 11:24:50 -0700 Date: Tue, 10 Dec 2013 11:24:50 -0700 Message-ID: <20131210112450.Horde.ICmaoBc0Ktf-6kbKct7e_Q6@bigworm.curecanti.org> From: Michael M Slusarz To: imapext@ietf.org References: <20131008141122.25649.73956.idtracker@ietfa.amsl.com> <20131206171614.Horde.I3inQX4SvzGsmVDXyHl8fg9@bigworm.curecanti.org> <52A5ADDE.6070308@isode.com> <1386591441.1524.57290317.6E0F3C3F@webmail.messagingengine.com> <44D2E502-427F-474B-A790-282733CB1B83@iki.fi> In-Reply-To: <44D2E502-427F-474B-A790-282733CB1B83@iki.fi> User-Agent: Internet Messaging Program (IMP) H5 (6.2.0-git) Accept-Language: en X-Originating-IP: 64.134.27.125 X-Remote-Browser: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:25.0) Gecko/20100101 Firefox/25.0 Content-Type: text/plain; charset=UTF-8; format=flowed; DelSp=Yes MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 8bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1386699922; bh=SbOeVp9Zg1UAYCh5EHymLU398mnyiVjQ2hay+vspnjA=; h=Received:Received:Received:Received:Date:Message-ID:From:To: Subject:Content-Type:MIME-Version; b=rskLmQtoHJzFQAEyqeEEiRQJF1/hIRxjtawdZReaongWdK3Vo4Gdf4qtjROxsjS0w gSV/XYtp/WSWJzWHE99YSfUYLnS7nDO+uVMdNBCNSx/WmYQWLIQdteEx6y8ukZMVjB Q1GC2oCk1fgs+yBdBIJ5AWHgYNtAijwjQPElMEe4E7/bIybGjeBuyv+0i5gVLNvWhk 5xqTycd9pPuzhvVeWmiqm7FjG785rlbUs4rZ0HehfZ41PoY6VIKHSfgqx73j78dK6R u9l4fK0nB5zNkws+w7js9qYDVjsZm+ejhF6e4bKLb5n41nFFE73ySHaxJM6JgQz+vV ecNJ73U+07TXQ== Subject: Re: [imapext] Should CONDSTORE require automatic use of UID FETCH data items in responses? (was I-D Action: draft-ietf-qresync-rfc5162bis-03.txt) X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Dec 2013 18:25:29 -0000 Quoting Timo Sirainen : > On 9.12.2013, at 14.17, Bron Gondwana wrote: > >>>> * UID information in FETCH responses is only required if QRESYNC is >>>> enabled (3.2.3). However, the only examples of what happens when an >>>> external agent triggers an unsolicited FETCH response appear in the >>>> CONDSTORE section, and it doesn't include UID information. E.g., from >>>> Page 17: >>>> >>>> C: C360 NOOP >>>> S: * 7 FETCH (FLAGS (\Deleted) MODSEQ (12121245160)) >>>> S: C360 OK Noop completed >>>> >>>> While discussing QRESYNC prospectively within the CONDSTORE definition >>>> might be a bit confusing, it is also the logical place to do so given >>>> the current examples. At least a mention might be made to 3.2.3: >>>> 'Note that this FETCH response MUST include UID data if both a >>>> "CONDSTORE enabling command" has been issued and QRESYNC is supported >>>> by the server'. >>> Hmm, this brings an interesting question: should the requirement to >>> return UIDs also apply to CONDSTORE? >> >> I would vote yes - CONDSTORE enabling command means UIDs in everything. >> >> It's very unlikely to break any existing clients. > > It wouldn’t hurt, but I’m not sure if it would help much either. I > think I proposed this somewhere, but I can’t find where. Or at least > not in errata. Errata #1807 to RFC 5162. > Anyway, I think the point was that with QRESYNC the client wouldn’t > necessarily have to keep MSN <-> UID mapping, since it gets VANISHED > replies. With only CONDSTORE enabled the client would still have to > keep the mapping to handle EXPUNGE replies. Agreed. As Bron points out, it's not going to break any existing clients - clients still need to keep a MSN/UID mapping for this particular CONDSTORE behavior regardless of the presence of UIDs. Given the assumption elsewhere in the draft that it is expected server authors will implement both extensions at the same time, it would be easiest to simply make all FETCH responses look the same. And it eliminates the extra work documentation-wise to describe two different FETCH responses based on very subtle environment differences that apply to only a very few client authors. michael ___________________________________ Michael Slusarz [slusarz@horde.org] From alexey.melnikov@isode.com Wed Dec 11 05:50:17 2013 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CD831ADEBE for ; Wed, 11 Dec 2013 05:50:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lRX7H5re1VDZ for ; Wed, 11 Dec 2013 05:50:15 -0800 (PST) Received: from statler.isode.com (statler.isode.com [62.3.217.254]) by ietfa.amsl.com (Postfix) with ESMTP id 457A11ADDDA for ; Wed, 11 Dec 2013 05:50:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1386769809; d=isode.com; s=selector; i=@isode.com; bh=20hbl+9yWuPQfxf5FvT49WYHPRMPV9czBSpxkQWnJA8=; 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=D6FJ7kmtvx2/uxrY9v8tLLjbvJ8OZWQOh5loPcNwllvdNSrlyabbEu1lCFPpaG7nIlbooW k2MIYAQKuRlQo79zx0e9Wj62qGvw3qgTT7vb3rMm/uAqIMaVHICQDFrPruu325q6Zr+98w rbJoHF+dQqwTMtAA9g1nGFLzitpWdLU=; Received: from [172.16.1.29] (richard.isode.com [62.3.217.249]) by statler.isode.com (submission channel) via TCP with ESMTPA id ; Wed, 11 Dec 2013 13:50:08 +0000 Message-ID: <52A86D96.4030808@isode.com> Date: Wed, 11 Dec 2013 13:50:14 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 To: imapext@ietf.org References: <88314AE8-0795-4912-8A9B-5BBA13525E4F@iki.fi> <20131209124209.GA1028@gulbrandsen.priv.no> <1386645726.26378.57638805.379F37C0@webmail.messagingengine.com> In-Reply-To: <1386645726.26378.57638805.379F37C0@webmail.messagingengine.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [imapext] Making mod-sequence 63 bit (was Re: I-D Action: draft-ietf-qresync-rfc5162bis-03.txt) X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Dec 2013 13:50:17 -0000 On 10/12/2013 03:22, Bron Gondwana wrote: > On Mon, Dec 9, 2013, at 11:42 PM, Arnt Gulbrandsen wrote: >> On Mon, Dec 09, 2013 at 02:30:33PM +0200, Timo Sirainen wrote: >>> On 9.12.2013, at 14.05, Adrien de Croy wrote: >>>> When I first saw the very long UIDs, I found it hard to compare them. This made it more effort to see what was going on. There's also more chance of a typo, as in the UID for #4 (12121130956 should read 12121230956), which makes the example incorrect. >>> Then again if only short modseqs are shown everywhere, client implementors are going to use 32bit ints for them.. >> I completely agree with Timo. >> >> It's easy to make them comparable at a glance, just make sure there's >> always a few digits more and the top digit increases. It's easy to >> tell that 38823478494237 > 22347894237. >> >> 64-bit numbers are nice, they give us range. (Did I say 64? Oh foo. I >> meant 63. Must be kind to the java clients.) > It sure was nice in Cyrus switching to 64 bits for quota and ditching uquota_t in > the process. 63 bits ought to be enough for anybody. This is an issue that Dave Cridland also raised privately with me, but I forgot to report it on the mailing list. So, should the new document require use of 63 bit mod-sequences? From arnt@gulbrandsen.priv.no Wed Dec 11 06:50:04 2013 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C3C11ADF6B for ; Wed, 11 Dec 2013 06:50:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tI_aA0gAFV5W for ; Wed, 11 Dec 2013 06:50:03 -0800 (PST) Received: from strange.aox.org (strange.aox.org [IPv6:2001:4d88:100c::1]) by ietfa.amsl.com (Postfix) with ESMTP id 075FB1ADF50 for ; Wed, 11 Dec 2013 06:50:02 -0800 (PST) Received: from fri.gulbrandsen.priv.no (localhost [127.0.0.1]) by strange.aox.org (Postfix) with ESMTP id 6DABEFA0013; Wed, 11 Dec 2013 14:49:56 +0000 (UTC) Received: from arnt@gulbrandsen.priv.no by fri.gulbrandsen.priv.no (Archiveopteryx 3.2.0) with esmtpsa id 1386773395-29127-29126/11/12; Wed, 11 Dec 2013 14:49:55 +0000 Date: Wed, 11 Dec 2013 15:50:04 +0100 From: Arnt Gulbrandsen To: imapext@ietf.org Message-Id: <20131211145000.GA5577@gulbrandsen.priv.no> References: <88314AE8-0795-4912-8A9B-5BBA13525E4F@iki.fi> <20131209124209.GA1028@gulbrandsen.priv.no> <1386645726.26378.57638805.379F37C0@webmail.messagingengine.com> <52A86D96.4030808@isode.com> In-Reply-To: <52A86D96.4030808@isode.com> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [imapext] Making mod-sequence 63 bit (was Re: I-D Action: draft-ietf-qresync-rfc5162bis-03.txt) X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Dec 2013 14:50:04 -0000 On Wed, Dec 11, 2013 at 01:50:14PM +0000, Alexey Melnikov wrote: > This is an issue that Dave Cridland also raised privately with me, > but I forgot to report it on the mailing list. So, should the new > document require use of 63 bit mod-sequences? Yes. Arnt From tss@iki.fi Wed Dec 11 06:53:38 2013 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4ADCC1ADF54 for ; Wed, 11 Dec 2013 06:53:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J6GKN17x3hgj for ; Wed, 11 Dec 2013 06:53:36 -0800 (PST) Received: from dovecot.org (dovecot.org [193.210.130.67]) by ietfa.amsl.com (Postfix) with ESMTP id 2F52B1AD9B7 for ; Wed, 11 Dec 2013 06:53:36 -0800 (PST) Received: from [10.217.1.108] (vfw03.dovecot.fi [88.194.145.100]) by dovecot.org (Postfix) with ESMTP id A6DB11AE87C4 for ; Wed, 11 Dec 2013 16:53:29 +0200 (EET) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) From: Timo Sirainen In-Reply-To: <20131211145000.GA5577@gulbrandsen.priv.no> Date: Wed, 11 Dec 2013 16:53:22 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <88314AE8-0795-4912-8A9B-5BBA13525E4F@iki.fi> <20131209124209.GA1028@gulbrandsen.priv.no> <1386645726.26378.57638805.379F37C0@webmail.messagingengine.com> <52A86D96.4030808@isode.com> <20131211145000.GA5577@gulbrandsen.priv.no> To: imapext@ietf.org X-Mailer: Apple Mail (2.1822) Subject: Re: [imapext] Making mod-sequence 63 bit (was Re: I-D Action: draft-ietf-qresync-rfc5162bis-03.txt) X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Dec 2013 14:53:38 -0000 On 11.12.2013, at 16.50, Arnt Gulbrandsen = wrote: > On Wed, Dec 11, 2013 at 01:50:14PM +0000, Alexey Melnikov wrote: >> This is an issue that Dave Cridland also raised privately with me, >> but I forgot to report it on the mailing list. So, should the new >> document require use of 63 bit mod-sequences? >=20 > Yes. Yeah, 63bit is enough, no point in making people=92s life more difficult = than it has to be. From brong@fastmail.fm Wed Dec 11 12:51:17 2013 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF9451AE052 for ; Wed, 11 Dec 2013 12:51:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qcuanzz01I5Q for ; Wed, 11 Dec 2013 12:51:16 -0800 (PST) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) by ietfa.amsl.com (Postfix) with ESMTP id 1DB9C1ADF55 for ; Wed, 11 Dec 2013 12:51:15 -0800 (PST) Received: from compute2.internal (compute2.nyi.mail.srv.osa [10.202.2.42]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id 371E521E11 for ; Wed, 11 Dec 2013 15:51:05 -0500 (EST) Received: from web2 ([10.202.2.212]) by compute2.internal (MEProxy); Wed, 11 Dec 2013 15:51:05 -0500 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= mUHnnLTyMYrtHxXHdBJr2CA3DHc=; b=l/6dlQ/ztLvCbP1Pzy9Hze6M//49pQsn rhRg0bJ75aqDAvSCYkEfwIcNcRluNSYMl2NQ20qOe3rN2/T56AuicTW9igIWJn5Z DKPZnzMFc9K8fyK+DuztCwEjf+Lkq85O8r+tOLT+LbXZoVk9JYH9ES2OyoK7KjLj W4NyeM7NH4o= 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=mUHnnLTyMYrtHxXHdBJr2CA3DHc=; b=j4i S8wPd7gglx9VZvgNiLMRhIY4lmEh0s1is88o1eWP4bC+BuvQoJaMAzqL3vhvOAmS yh7HYGwxFrY9FKwUuScG7umjEhteUu81IPQasif60v1xXauKOkkvxoZ2EkZsgX80 0k//PLusiOizhh5ESBl959SX5tXJSZMvU4wIa2Iw= Received: by web2.nyi.mail.srv.osa (Postfix, from userid 99) id 10611540112; Wed, 11 Dec 2013 15:51:05 -0500 (EST) Message-Id: <1386795065.32371.58474953.6E0F0994@webmail.messagingengine.com> X-Sasl-Enc: hSz6NLO6UdlHEOVlRv3Vmp+6mydMG3wG9vEZtIaedMyd 1386795065 From: Bron Gondwana To: imapext@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" X-Mailer: MessagingEngine.com Webmail Interface - ajax-605a1389 In-Reply-To: References: <88314AE8-0795-4912-8A9B-5BBA13525E4F@iki.fi> <20131209124209.GA1028@gulbrandsen.priv.no> <1386645726.26378.57638805.379F37C0@webmail.messagingengine.com> <52A86D96.4030808@isode.com> <20131211145000.GA5577@gulbrandsen.priv.no> Date: Thu, 12 Dec 2013 07:51:05 +1100 Subject: Re: [imapext] Making mod-sequence 63 bit (was Re: I-D Action: draft-ietf-qresync-rfc5162bis-03.txt) X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Dec 2013 20:51:17 -0000 On Thu, Dec 12, 2013, at 01:53 AM, Timo Sirainen wrote: > On 11.12.2013, at 16.50, Arnt Gulbrandsen wrot= e: >=20 > > On Wed, Dec 11, 2013 at 01:50:14PM +0000, Alexey Melnikov wrote: > >> This is an issue that Dave Cridland also raised privately with me, > >> but I forgot to report it on the mailing list. So, should the new > >> document require use of 63 bit mod-sequences? > >=20 > > Yes. >=20 > Yeah, 63bit is enough, no point in making people=E2=80=99s life more diff= icult than it has to be. I agree (even if I do have to go fix my personal user where I intentionally= set the high bit to see what breaks...) Bron. --=20 Bron Gondwana brong@fastmail.fm From alexey.melnikov@isode.com Sat Dec 14 14:37:32 2013 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E24B1ADBCF for ; Sat, 14 Dec 2013 14:37:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.471 X-Spam-Level: X-Spam-Status: No, score=-0.471 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h0FFK_3BgcAO for ; Sat, 14 Dec 2013 14:37:29 -0800 (PST) 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 0637F1ADAEA for ; Sat, 14 Dec 2013 14:37:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1387060639; d=isode.com; s=selector; i=@isode.com; bh=+mv4MaLI1M3WkgYldtw8vsi58Dq/xgm9ID0gSWmuRME=; 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=XIri9znVP9MIqO038F4soIESSnKG7DoJ4epAylyXTgHC6de18mvpQfCfe4kdVaJ6y0hkQt 1NkiDxKpFR3oXd9M3MvKOHM+SQmN93x68WuL/VTt256Co4FJO3B2zV6gIT/aMzutYL4p2j hD2OsaVy7jxY7tImksVAekgB5PgPM0c=; Received: from [192.168.0.4] (cpc5-nmal20-2-0-cust24.19-2.cable.virginm.net [92.234.84.25]) by waldorf.isode.com (submission channel) via TCP with ESMTPSA id ; Sat, 14 Dec 2013 22:37:19 +0000 X-SMTP-Protocol-Errors: PIPELINING Message-ID: <52ACDDA1.9030903@isode.com> Date: Sat, 14 Dec 2013 22:37:21 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 To: Michael M Slusarz References: <20131008141122.25649.73956.idtracker@ietfa.amsl.com> <20131206171614.Horde.I3inQX4SvzGsmVDXyHl8fg9@bigworm.curecanti.org> In-Reply-To: <20131206171614.Horde.I3inQX4SvzGsmVDXyHl8fg9@bigworm.curecanti.org> 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-03.txt X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Dec 2013 22:37:33 -0000 Hi Michael, On 07/12/2013 00:16, Michael M Slusarz wrote: [...] > * UID information in FETCH responses is only required if QRESYNC is > enabled (3.2.3). However, the only examples of what happens when an > external agent triggers an unsolicited FETCH response appear in the > CONDSTORE section, and it doesn't include UID information. E.g., from > Page 17: > > C: C360 NOOP > S: * 7 FETCH (FLAGS (\Deleted) MODSEQ (12121245160)) > S: C360 OK Noop completed > > While discussing QRESYNC prospectively within the CONDSTORE definition > might be a bit confusing, it is also the logical place to do so given > the current examples. At least a mention might be made to 3.2.3: > 'Note that this FETCH response MUST include UID data if both a > "CONDSTORE enabling command" has been issued and QRESYNC is supported > by the server'. I think all responses of the Example 14 need to be updated. So yes, I've updated the draft to say something similar to what you suggested. Best Regards, Alexey From alexey.melnikov@isode.com Sat Dec 14 15:47:35 2013 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 515A91AD8DA for ; Sat, 14 Dec 2013 15:47:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.23 X-Spam-Level: ** X-Spam-Status: No, score=2.23 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, HTML_MESSAGE=0.001, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CjZrrI4wXphu for ; Sat, 14 Dec 2013 15:47:33 -0800 (PST) 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 DDAEB1ADF7A for ; Sat, 14 Dec 2013 15:34:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1387064035; d=isode.com; s=selector; i=@isode.com; bh=//iRuUJcrKOnPeheYs+Ccg//1Je5/1gQROrLdHtOIh0=; 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=YrU741snRhNWcoutsGKy4RVIr8295sjKdldJYt/T5MXTN1xTMNK1+mL21MuP2IpHbUEZgf l0o8OmhR03gcxsM4EBqLwWpc6d5GWsAStJHMrW4dSqv30OsgEyxUEqfyMwh24TFmFl6+v2 t22N50SIQA26SSkEM4ydaT7lcKlIXF8=; Received: from [192.168.0.4] (cpc5-nmal20-2-0-cust24.19-2.cable.virginm.net [92.234.84.25]) by waldorf.isode.com (submission channel) via TCP with ESMTPSA id ; Sat, 14 Dec 2013 23:33:55 +0000 X-SMTP-Protocol-Errors: PIPELINING Message-ID: <52ACEAE3.70905@isode.com> Date: Sat, 14 Dec 2013 23:33:55 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 To: Bron Gondwana References: <1386287986.3881.56114933.3A3FC70D@webmail.messagingengine.com> In-Reply-To: <1386287986.3881.56114933.3A3FC70D@webmail.messagingengine.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------050908010409040801030407" Cc: imapext@ietf.org Subject: Re: [imapext] WGLC on QRESYNC, Ending 6th December. X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Dec 2013 23:47:35 -0000 This is a multi-part message in MIME format. --------------050908010409040801030407 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 05/12/2013 23:59, Bron Gondwana wrote: > I only have one significant worry - and it starts in section 3.2. > /*The UNCHANGEDSINCE atomicity requirements are only on a single > keyword at a time.*/ > So starting here: > "If the mod-sequence of any metadata item on the message is equal to > or less than... then the requested operation is performed" Thank you for pointing this out. I agree that this is wrong, I think it should read: If the mod-sequence of every metadata item of the message affected by the STORE/UID STORE is equal to or less ... > My reading of that (any rather than every) is that you could do this: > C: TAG STORE 5 (UNCHANGED SINCE 5674) +FLAGS.SILENT ($FlagA $FlagB) > on a server which stores separate per-flag modseq, and get this response: > S: * 5 FETCH (UID 23 MODSEQ (5801) FLAGS ($FlagA)) > S: TAG OK [MODIFIED 5] Conditional Store failed > Where $FlagA gets set, but another session had set/removed $FlagB already. > ----- > Here's a real world example. A client uses the following keywords: > Junk NotJunk JunkRecorded. When it marks a message a junk it sets > both JunkRecorded and ONLY ONE of Junk or NotJunk. > A brand new mailbox has one message. > S: * 1 FETCH (UID 1 MODSEQ (1) FLAGS ()) > The first client marks the message as Junk > C: a01 STORE 1 (UNCHANGED SINCE 1) +FLAGS (Junk JunkRecorded) > S: * 1 FETCH (UID 1 MODSEQ (2) FLAGS (Junk JunkRecorded)) > S: TAG OK Conditional Store completed > And a second client marks the message as NonJunk > C: a01 STORE 1 (UNCHANGED SINCE 1) +FLAGS (NonJunk JunkRecorded) > S: * 1 FETCH (UID 1 MODSEQ (3) FLAGS (Junk JunkRecorded NonJunk)) > S: TAG OK [Modified 1] Conditional Store failed > .... clearly the end result is bogus - but this is what I see as the > logical result of allowing partial metadata updates to succeed > "atomically" when other metadata was unchanged. In this case the > 'NonJunk' flag was unchanged since MODSEQ 1 - and the 'JunkRecorded' > flag, which was supposed to protect against this problem, has failed. > Am I reading it wrong? > I would be a lot more comfortable if all metadata about a message was > unchanged if ANY of the requested operations were disallowed by the > UNCHANGEDSINCE rule. As per above, I think only affected metadata items should be considered. > (none of this applies in Cyrus, which only stores on MODSEQ per > message... but I still worry) > Regards, > Bron. > --------------050908010409040801030407 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 05/12/2013 23:59, Bron Gondwana wrote:

I only have one significant worry - and it starts in section 3.2.  The UNCHANGEDSINCE atomicity requirements are only on a single keyword at a time.
 
So starting here:
 
"If the mod-sequence of any metadata item on the message is equal to or less than... then the requested operation is performed"
Thank you for pointing this out. I agree that this is wrong, I think it should read:

  If the mod-sequence of every metadata item of the message affected by the STORE/UID STORE is equal to or less ...

 
My reading of that (any rather than every) is that you could do this:
 
C: TAG STORE 5 (UNCHANGED SINCE 5674) +FLAGS.SILENT ($FlagA $FlagB)
 
on a server which stores separate per-flag modseq, and get this response:
 
S: * 5 FETCH (UID 23 MODSEQ (5801) FLAGS ($FlagA))
S: TAG OK [MODIFIED 5] Conditional Store failed
 
Where $FlagA gets set, but another session had set/removed $FlagB already.
 
-----
 
Here's a real world example.  A client uses the following keywords:  Junk NotJunk JunkRecorded.  When it marks a message a junk it sets both JunkRecorded and ONLY ONE of Junk or NotJunk.
 
A brand new mailbox has one message.
 
S: * 1 FETCH (UID 1 MODSEQ (1) FLAGS ())
 
The first client marks the message as Junk
 
C: a01 STORE 1 (UNCHANGED SINCE 1) +FLAGS (Junk JunkRecorded)
S: * 1 FETCH (UID 1 MODSEQ (2) FLAGS (Junk JunkRecorded))
S: TAG OK Conditional Store completed
 
And a second client marks the message as NonJunk
 
C: a01 STORE 1 (UNCHANGED SINCE 1) +FLAGS (NonJunk JunkRecorded)
S: * 1 FETCH (UID 1 MODSEQ (3) FLAGS (Junk JunkRecorded NonJunk))
S: TAG OK [Modified 1] Conditional Store failed
 
.... clearly the end result is bogus - but this is what I see as the logical result of allowing partial metadata updates to succeed "atomically" when other metadata was unchanged.  In this case the 'NonJunk' flag was unchanged since MODSEQ 1 - and the 'JunkRecorded' flag, which was supposed to protect against this problem, has failed.
 
Am I reading it wrong?
 
I would be a lot more comfortable if all metadata about a message was unchanged if ANY of the requested operations were disallowed by the UNCHANGEDSINCE rule.
As per above, I think only affected metadata items should be considered.
(none of this applies in Cyrus, which only stores on MODSEQ per message... but I still worry)
 
Regards,
 
Bron.


--------------050908010409040801030407-- From alexey.melnikov@isode.com Sat Dec 14 15:51:14 2013 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C6821AD791 for ; Sat, 14 Dec 2013 15:51:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.47 X-Spam-Level: X-Spam-Status: No, score=-0.47 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, HTML_MESSAGE=0.001, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MyCo_8A3u1eN for ; Sat, 14 Dec 2013 15:51:12 -0800 (PST) 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 2F5321ADF91 for ; Sat, 14 Dec 2013 15:38:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1387064290; d=isode.com; s=selector; i=@isode.com; bh=MZP/GW58JQusZet1QtK60zZ4e4cstEqgjid29NecfgE=; 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=TBGXRi8VrW5MYZHSGRE34cq3HZXm8uB+/bvc093JmF4A8k7oQyuq5SOPEZ855s53V9zMwy pnrfz3mseSZM6KUubU+EkydTYQPUd9piwR4ATBkzYZOxIIGmM67OkkeDMTNGBhcMb64XXs DnomqQsJAu1GR4xOj60zhB2XKeP0TtM=; Received: from [192.168.0.4] (cpc5-nmal20-2-0-cust24.19-2.cable.virginm.net [92.234.84.25]) by waldorf.isode.com (submission channel) via TCP with ESMTPSA id ; Sat, 14 Dec 2013 23:38:10 +0000 X-SMTP-Protocol-Errors: PIPELINING Message-ID: <52ACEBE3.5090804@isode.com> Date: Sat, 14 Dec 2013 23:38:11 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 To: Jayantheesh S B References: <1386021084.78345.YahooMailNeo@web160203.mail.bf1.yahoo.com> <9576257CC412C5B483A28644@96B2F16665FF96BAE59E9B90> <1386028949.42306.YahooMailNeo@web160201.mail.bf1.yahoo.com> <1386109277.12951.YahooMailNeo@web160203.mail.bf1.yahoo.com> <1386113435.16903.55176845.6FE3D167@webmail.messagingengine.com> <6C31A20D5301214284D0C838A6B69542CFBD66FC2A@StaEx7mb3.telecom.sna.samsung.com> <6C31A20D5301214284D0C838A6B69542CFBD66FC60@StaEx7mb3.telecom.sna.samsung.com> <6C31A20D5301214284D0C838A6B69542CFBD66FD91@StaEx7mb3.telecom.sna.samsung.com> In-Reply-To: <6C31A20D5301214284D0C838A6B69542CFBD66FD91@StaEx7mb3.telecom.sna.samsung.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------010100060109010708090605" Cc: "imapext@ietf.org" , Dave Cridland Subject: Re: [imapext] [lemonade] Regarding CONDSTORE IMAP extension X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Dec 2013 23:51:14 -0000 --------------010100060109010708090605 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: quoted-printable Hi, On 05/12/2013 16:27, Jayantheesh S B wrote: > > Thanks Dave. > > It's clear in=20 > http://datatracker.ietf.org/doc/draft-ietf-qresync-rfc4551bis/ draft. > > Regards, > > Jay > > *From:*Dave Cridland [mailto:dave@cridland.net] > *Sent:* Wednesday, December 04, 2013 3:09 PM > *To:* Jayantheesh S B > *Cc:* imapext@ietf.org > *Subject:* Re: [imapext] [lemonade] Regarding CONDSTORE IMAP extension > > On Wed, Dec 4, 2013 at 7:56 PM, Jayantheesh S B > wrote: > > Thanks Dave for your detailed explanation. > > Coming to my initial question. If IMAP server advertises the > CONDSTORE capability indicates the support of IMAP CONDSTORE > extension. > > =B7For SELECT/EXAMINE command IMAP server should send the > HIGHESTMODESQ value modified with respect to change in the mailbox > > (Or) > > =B7IMAP Client should send ENABLE CONDSTORE to enable the service > for that session to get the correct HIGHESTMODSEQ value from server. > I updated the draft to say the latter. Any other CONDSTORE enabling=20 command would have the same effect. > > Please clarify. > > Can I first check if you've read the latest draft: > > http://datatracker.ietf.org/doc/draft-ietf-qresync-rfc4551bis/ > > I'm hoping this should make the protocol clearer, and if it's still=20 > not clear from this document, we should be addressing this now. > --------------010100060109010708090605 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Hi,

On 05/12/2013 16:27, Jayantheesh S B wrote:

Thanks Dave.

 

It’s clear in http://datatracker.ietf.org/doc/draft-ietf-qresync-rfc4551bis/ draft.

 

Regards,

Jay

From: Dave Cridland [mailto:dave@cridland.net]
Sent: Wednesday, December 04, 2013 3:09 PM
To: Jayantheesh S B
Cc: imapext@ietf.org
Subject: Re: [imapext] [lemonade] Regarding CONDSTORE IMAP extension

 

On Wed, Dec 4, 2013 at 7:56 PM, Jayantheesh S B <j.sb@sta.samsung.com> wrote:

Thanks Dave for your detailed explanation.

 

Coming to my initial question. If IMAP server advertises the CONDSTORE capability indicates the support of IMAP CONDSTORE extension.

 

·         For SELECT/EXAMINE command IMAP server should send the HIGHESTMODESQ value modified with respect to change in the mailbox

(Or)

·         IMAP Client should send ENABLE CONDSTORE to enable the service for that session to get the correct HIGHESTMODSEQ value from server.

I updated the draft to say the latter. Any other CONDSTORE enabling command would have the same effect.

 

Please clarify.

 

 

Can I first check if you've read the latest draft:

 

 

I'm hoping this should make the protocol clearer, and if it's still not clear from this document, we should be addressing this now.



--------------010100060109010708090605-- From brong@fastmail.fm Sat Dec 14 16:18:19 2013 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 323111ADEBF for ; Sat, 14 Dec 2013 16:18:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.299 X-Spam-Level: X-Spam-Status: No, score=-1.299 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vf-NJCdc7eKI for ; Sat, 14 Dec 2013 16:18:15 -0800 (PST) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) by ietfa.amsl.com (Postfix) with ESMTP id 8F9931ADF30 for ; Sat, 14 Dec 2013 16:18:14 -0800 (PST) Received: from compute2.internal (compute2.nyi.mail.srv.osa [10.202.2.42]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id 231272080B; Sat, 14 Dec 2013 19:18:07 -0500 (EST) Received: from web5 ([10.202.2.215]) by compute2.internal (MEProxy); Sat, 14 Dec 2013 19:18:07 -0500 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= QJBJXGKEKpwUMgShJPSClNUdB+M=; b=iYgM39xR0jslmA1zbB5OX9M02SHbIk3J uy/bwKZ1JfPhqoIIrBDlUCmWVTpdTO+NYUx/Zx+hIYQ5PFp51kai9DAaZQ/j10M8 Fmxu/zwuIjZ6JBmZ1cVMZfyyKvaC2uRorOUrHT/7gmmkmxXfqLfurM21mLIrPj0s ra/mrFIT45Q= 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=QJBJXGKEKpwUMgShJPSClNUdB+M=; b=Q00 qRfPseLu6b/dXwqQ8Ri2+75WzxoWx73i5l5VfUMeKbdRoUm+GxxjPyOB+3Hb9A/O CK7jGOaqRxpoSi5uPAj/cxXW57TGyYGol6ZGewWxTRgz9JvaPIWCfskBMpcCXBr3 DeQzBcxEc1fzu9m6yhvpstTQqbdB+KWzbKowquU4= Received: by web5.nyi.mail.srv.osa (Postfix, from userid 99) id E9541BA4F2A; Sat, 14 Dec 2013 19:18:06 -0500 (EST) Message-Id: <1387066686.21285.59692389.257ED33B@webmail.messagingengine.com> X-Sasl-Enc: PGEI269tbOGQ0ErKRlpBM6t3PObaOP2Pap7SHuC7dDLV 1387066686 From: Bron Gondwana To: Alexey Melnikov MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="_----------=_1387066686212852"; charset="utf-8" X-Mailer: MessagingEngine.com Webmail Interface - ajax-7f24e732 In-Reply-To: <52ACEAE3.70905@isode.com> References: <1386287986.3881.56114933.3A3FC70D@webmail.messagingengine.com> <52ACEAE3.70905@isode.com> Date: Sun, 15 Dec 2013 11:18:06 +1100 Cc: imapext@ietf.org Subject: Re: [imapext] WGLC on QRESYNC, Ending 6th December. X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Dec 2013 00:18:19 -0000 This is a multi-part message in MIME format. --_----------=_1387066686212852 Content-Transfer-Encoding: 7bit Content-Type: text/plain On Sun, Dec 15, 2013, at 10:33 AM, Alexey Melnikov wrote: On 05/12/2013 23:59, Bron Gondwana wrote: I only have one significant worry - and it starts in section 3.2. The UNCHANGEDSINCE atomicity requirements are only on a single keyword at a time. So starting here: "If the mod-sequence of any metadata item on the message is equal to or less than... then the requested operation is performed" Thank you for pointing this out. I agree that this is wrong, I think it should read: If the mod-sequence of every metadata item of the message affected by the STORE/UID STORE is equal to or less ... That works for me. I would be a lot more comfortable if all metadata about a message was unchanged if ANY of the requested operations were disallowed by the UNCHANGEDSINCE rule. As per above, I think only affected metadata items should be considered. I'm happy with that as the hard requirement. Of course if a server checks everything and rejects, it's just less efficient - because the client has to re-fetch all the metadata before trying to apply the change. It won't break things. We're talking something which is (hopefully) very rare anyway - but it's important to fail safe :) Bron. -- Bron Gondwana brong@fastmail.fm --_----------=_1387066686212852 Content-Transfer-Encoding: 7bit Content-Type: text/html
 
On Sun, Dec 15, 2013, at 10:33 AM, Alexey Melnikov wrote:
On 05/12/2013 23:59, Bron Gondwana wrote:
 
 
I only have one significant worry - and it starts in section 3.2.  The UNCHANGEDSINCE atomicity requirements are only on a single keyword at a time.
 
So starting here:
 
"If the mod-sequence of any metadata item on the message is equal to or less than... then the requested operation is performed"
Thank you for pointing this out. I agree that this is wrong, I think it should read:
 
  If the mod-sequence of every metadata item of the message affected by the STORE/UID STORE is equal to or less ...
 
That works for me.
 
I would be a lot more comfortable if all metadata about a message was unchanged if ANY of the requested operations were disallowed by the UNCHANGEDSINCE rule.
 
As per above, I think only affected metadata items should be considered.
 
I'm happy with that as the hard requirement.  Of course if a server checks everything and rejects, it's just less efficient - because the client has to re-fetch all the metadata before trying to apply the change.  It won't break things.  We're talking something which is (hopefully) very rare anyway - but it's important to fail safe :)
 
Bron.
 
--
Bron Gondwana
brong@fastmail.fm
 
--_----------=_1387066686212852-- From alexey.melnikov@isode.com Mon Dec 16 04:23:26 2013 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADB361AE2FC for ; Mon, 16 Dec 2013 04:23:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.539 X-Spam-Level: X-Spam-Status: No, score=-2.539 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q0Nk7Spvs-Qf for ; Mon, 16 Dec 2013 04:23:24 -0800 (PST) Received: from statler.isode.com (statler.isode.com [62.3.217.254]) by ietfa.amsl.com (Postfix) with ESMTP id 653D11ADF89 for ; Mon, 16 Dec 2013 04:23:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1387063392; d=isode.com; s=selector; i=@isode.com; bh=IQQln8iH4kOznK9H9vNl9fniICY0iNKKsCuScw/u0w4=; 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=ew/o9isj6Z8VbttrN+klXw/ZikiJRKlDsM2uSI06al8GlwJWy9hMwb1RqOWFrtg6X5O4e3 0RENUElAnSmDLj0ohAOknhsL3GAHd/vBKfNCIbOVB91J6ZihrxS8sImWipe0obta50SlzO OiAAJ5e5qkut85rR/jloOsuNIqu5xV8=; Received: from [192.168.0.4] (cpc5-nmal20-2-0-cust24.19-2.cable.virginm.net [92.234.84.25]) by statler.isode.com (submission channel) via TCP with ESMTPSA id ; Sat, 14 Dec 2013 23:23:12 +0000 X-SMTP-Protocol-Errors: PIPELINING Message-ID: <52ACE861.8060709@isode.com> Date: Sat, 14 Dec 2013 23:23:13 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 To: Michael M Slusarz References: <20131008141122.25649.73956.idtracker@ietfa.amsl.com> <20131206171614.Horde.I3inQX4SvzGsmVDXyHl8fg9@bigworm.curecanti.org> <52ACDDA1.9030903@isode.com> In-Reply-To: <52ACDDA1.9030903@isode.com> 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-03.txt X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Dec 2013 12:23:26 -0000 On 14/12/2013 22:37, Alexey Melnikov wrote: > Hi Michael, > > On 07/12/2013 00:16, Michael M Slusarz wrote: > [...] >> * UID information in FETCH responses is only required if QRESYNC is >> enabled (3.2.3). However, the only examples of what happens when an >> external agent triggers an unsolicited FETCH response appear in the >> CONDSTORE section, and it doesn't include UID information. E.g., >> from Page 17: >> >> C: C360 NOOP >> S: * 7 FETCH (FLAGS (\Deleted) MODSEQ (12121245160)) >> S: C360 OK Noop completed >> >> While discussing QRESYNC prospectively within the CONDSTORE >> definition might be a bit confusing, it is also the logical place to >> do so given the current examples. At least a mention might be made >> to 3.2.3: 'Note that this FETCH response MUST include UID data if >> both a "CONDSTORE enabling command" has been issued and QRESYNC is >> supported by the server'. > I think all responses of the Example 14 need to be updated. So yes, > I've updated the draft to say something similar to what you suggested. I also made the requirement to include UID information a SHOULD level requirement for CONDSTORE. This would encourage new implementations to do that without breaking existing CONDSTORE-only implementations. From j.sb@sta.samsung.com Mon Dec 16 08:52:16 2013 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C727C1AE35E for ; Mon, 16 Dec 2013 08:52:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.438 X-Spam-Level: X-Spam-Status: No, score=-2.438 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M0m2xEx5TIK8 for ; Mon, 16 Dec 2013 08:52:13 -0800 (PST) Received: from cuda4.sta.samsung.com (mailedge.sta.samsung.com [63.166.115.23]) by ietfa.amsl.com (Postfix) with ESMTP id 8F35B1AE079 for ; Mon, 16 Dec 2013 08:52:13 -0800 (PST) X-ASG-Debug-ID: 1387212731-056fcf579992f7d0001-Ao1j2H Received: from StaEx7mb3.telecom.sna.samsung.com ([105.52.12.125]) by cuda4.sta.samsung.com with ESMTP id DsICkyPMlWDpLFhM; Mon, 16 Dec 2013 10:52:11 -0600 (CST) X-Barracuda-Envelope-From: j.sb@sta.samsung.com X-Barracuda-RBL-Trusted-Forwarder: 105.52.12.125 X-ASG-Whitelist: Client Received: from STAEX7MB3.telecom.sna.samsung.com ([fe80::2da2:a10c:2286:604e]) by StaEx7mb3.telecom.sna.samsung.com ([fe80::2da2:a10c:2286:604e%21]) with mapi; Mon, 16 Dec 2013 10:52:11 -0600 From: Jayantheesh S B X-Barracuda-BWL-IP: fe80::2da2:a10c:2286:604e To: Alexey Melnikov Date: Mon, 16 Dec 2013 10:52:09 -0600 Thread-Topic: [imapext] [lemonade] Regarding CONDSTORE IMAP extension X-ASG-Orig-Subj: RE: [imapext] [lemonade] Regarding CONDSTORE IMAP extension Thread-Index: Ac75JY4zoR4VqkgXR8CDL54yTkZNygBWYFew Message-ID: <6C31A20D5301214284D0C838A6B69542CFBD7B38E8@StaEx7mb3.telecom.sna.samsung.com> References: <1386021084.78345.YahooMailNeo@web160203.mail.bf1.yahoo.com> <9576257CC412C5B483A28644@96B2F16665FF96BAE59E9B90> <1386028949.42306.YahooMailNeo@web160201.mail.bf1.yahoo.com> <1386109277.12951.YahooMailNeo@web160203.mail.bf1.yahoo.com> <1386113435.16903.55176845.6FE3D167@webmail.messagingengine.com> <6C31A20D5301214284D0C838A6B69542CFBD66FC2A@StaEx7mb3.telecom.sna.samsung.com> <6C31A20D5301214284D0C838A6B69542CFBD66FC60@StaEx7mb3.telecom.sna.samsung.com> <6C31A20D5301214284D0C838A6B69542CFBD66FD91@StaEx7mb3.telecom.sna.samsung.com> <52ACEBE3.5090804@isode.com> In-Reply-To: <52ACEBE3.5090804@isode.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_6C31A20D5301214284D0C838A6B69542CFBD7B38E8StaEx7mb3tele_" MIME-Version: 1.0 X-Barracuda-Connect: UNKNOWN[105.52.12.125] X-Barracuda-Start-Time: 1387212731 X-Barracuda-URL: http://65.169.250.23:8000/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sta.samsung.com X-Barracuda-BRTS-Status: 1 Cc: "imapext@ietf.org" , Dave Cridland Subject: Re: [imapext] [lemonade] Regarding CONDSTORE IMAP extension X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Dec 2013 16:52:17 -0000 --_000_6C31A20D5301214284D0C838A6B69542CFBD7B38E8StaEx7mb3tele_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thanks Alexey. From: Alexey Melnikov [mailto:alexey.melnikov@isode.com] Sent: Saturday, December 14, 2013 6:38 PM To: Jayantheesh S B Cc: Dave Cridland; imapext@ietf.org Subject: Re: [imapext] [lemonade] Regarding CONDSTORE IMAP extension Hi, On 05/12/2013 16:27, Jayantheesh S B wrote: Thanks Dave. It's clear in http://datatracker.ietf.org/doc/draft-ietf-qresync-rfc4551bis= / draft. Regards, Jay From: Dave Cridland [mailto:dave@cridland.net] Sent: Wednesday, December 04, 2013 3:09 PM To: Jayantheesh S B Cc: imapext@ietf.org Subject: Re: [imapext] [lemonade] Regarding CONDSTORE IMAP extension On Wed, Dec 4, 2013 at 7:56 PM, Jayantheesh S B > wrote: Thanks Dave for your detailed explanation. Coming to my initial question. If IMAP server advertises the CONDSTORE capa= bility indicates the support of IMAP CONDSTORE extension. * For SELECT/EXAMINE command IMAP server should send the HIGHESTMOD= ESQ value modified with respect to change in the mailbox (Or) * IMAP Client should send ENABLE CONDSTORE to enable the service fo= r that session to get the correct HIGHESTMODSEQ value from server. I updated the draft to say the latter. Any other CONDSTORE enabling command= would have the same effect. Please clarify. Can I first check if you've read the latest draft: http://datatracker.ietf.org/doc/draft-ietf-qresync-rfc4551bis/ I'm hoping this should make the protocol clearer, and if it's still not cle= ar from this document, we should be addressing this now. --_000_6C31A20D5301214284D0C838A6B69542CFBD7B38E8StaEx7mb3tele_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

= Thanks Alexey.

 

Fr= om: Alexey Melnikov [mailto:alexey.melnikov@isode.com] =
Sent: Saturday, December 14, 2013 6:38 PM
To: Jayanthe= esh S B
Cc: Dave Cridland; imapext@ietf.org
Subject: Re= : [imapext] [lemonade] Regarding CONDSTORE IMAP extension=

 

Hi,

On 05/12/2013 16:27, Jayantheesh S B wrote:<= /p>

Thanks Dave.

 <= /o:p>

It’s clear in http://datatracker.ietf.o= rg/doc/draft-ietf-qresync-rfc4551bis/ draft.

 

Reg= ards,

Jay

From: Dave Cridland [mailto:dave@cridland.net]
Sent: Wednesday, December 0= 4, 2013 3:09 PM
To: Jayantheesh S B
Cc: imapext@ietf.org
Subject: Re: [imapext] = [lemonade] Regarding CONDSTORE IMAP extension

 

On Wed, Dec 4, = 2013 at 7:56 PM, Jayantheesh S B <j.sb@sta.samsung.com> wrote:

=

Thanks Dave for your detailed ex= planation.

 

=

Coming to my initial question. If IMAP server advertises the = CONDSTORE capability indicates the support of IMAP CONDSTORE extension.

 

·     &nbs= p;   For SELECT/EXAMINE command IMAP server should = send the HIGHESTMODESQ value modified with respect to change in the mailbox=

(Or)

· &nb= sp;       IMAP Client should se= nd ENABLE CONDSTORE to enable the service for that session to get the corre= ct HIGHESTMODSEQ value from server.

I updated the dr= aft to say the latter. Any other CONDSTORE enabling command would have the = same effect.

<= p class=3DMsoNormal style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:= auto'> 

Please clarify.

 

 

= Can I first check if you've read the latest draft:

 

 

I'm hoping this should make the protocol clearer, and if it= 's still not clear from this document, we should be addressing this now.

 

= --_000_6C31A20D5301214284D0C838A6B69542CFBD7B38E8StaEx7mb3tele_-- From internet-drafts@ietf.org Mon Dec 16 10:50:42 2013 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8A981AE12B; Mon, 16 Dec 2013 10:50:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YfTBSInOhKBB; Mon, 16 Dec 2013 10:50:41 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 138941AE0C9; Mon, 16 Dec 2013 10:50:41 -0800 (PST) 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.83.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131216185040.21751.60172.idtracker@ietfa.amsl.com> Date: Mon, 16 Dec 2013 10:50:40 -0800 Cc: imapext@ietf.org Subject: [imapext] I-D Action: draft-ietf-qresync-rfc5162bis-05.txt X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.15 List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Dec 2013 18:50:43 -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 Extensions for Conditional STORE Operation or Quick= Flag Changes Resynchronization (CONDSTORE) and Quick Mailbox Resynchroniza= tion (QRESYNC) Author(s) : Alexey Melnikov Dave Cridland Filename : draft-ietf-qresync-rfc5162bis-05.txt Pages : 49 Date : 2013-12-16 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 of the specific message being looked up) 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 additionally defines another IMAP 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-05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-qresync-rfc5162bis-05 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 Mon Dec 16 11:01:29 2013 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37A591AE11F for ; Mon, 16 Dec 2013 11:01:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.539 X-Spam-Level: X-Spam-Status: No, score=-2.539 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n-RB9gA9jADV for ; Mon, 16 Dec 2013 11:01:27 -0800 (PST) Received: from waldorf.isode.com (waldorf.isode.com [62.3.217.251]) by ietfa.amsl.com (Postfix) with ESMTP id B7C631AE138 for ; Mon, 16 Dec 2013 11:01:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1387220483; d=isode.com; s=selector; i=@isode.com; bh=0wTxhVMsSEfmIK5A0w7R6gWEelxAWUQzl/Yg625Cmds=; 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=EpwV17I/KOpNUJwEa08343LPxNPME2zn6ruOyRV7rVrJ4nmnRURUJdO5ficOZce5gVhCD5 zEgQtNzvFtevEU3X+AnCz2MVHxZBcTg418X6dLAd9hoBh8XDTe2QrcQxsHnRUMtOVBDJ1I tuSRkLrQCWwdWPcAxF7XRL1hCPJI2H4=; Received: from [192.168.0.4] (cpc5-nmal20-2-0-cust24.19-2.cable.virginm.net [92.234.84.25]) by waldorf.isode.com (submission channel) via TCP with ESMTPSA id ; Mon, 16 Dec 2013 19:01:23 +0000 X-SMTP-Protocol-Errors: PIPELINING Message-ID: <52AF4E01.9030600@isode.com> Date: Mon, 16 Dec 2013 19:01:21 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 To: qresync WG References: <20131216185040.21751.60172.idtracker@ietfa.amsl.com> In-Reply-To: <20131216185040.21751.60172.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-rfc5162bis-05.txt X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Dec 2013 19:01:29 -0000 Hi everybody, On 16/12/2013 18:50, 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 Extensions for Conditional STORE Operation or Quick Flag Changes Resynchronization (CONDSTORE) and Quick Mailbox Resynchronization (QRESYNC) > Author(s) : Alexey Melnikov > Dave Cridland > Filename : draft-ietf-qresync-rfc5162bis-05.txt > Pages : 49 > Date : 2013-12-16 This version addresses all known issues (include 63-bit mod-sequences) other than rewrite of the Abstract and the Introduction. From brong@fastmail.fm Tue Dec 17 03:07:44 2013 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4931A1AE13C for ; Tue, 17 Dec 2013 03:07:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DFnNcTFbweYb for ; Tue, 17 Dec 2013 03:07:42 -0800 (PST) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) by ietfa.amsl.com (Postfix) with ESMTP id 97F531ADFA6 for ; Tue, 17 Dec 2013 03:07:42 -0800 (PST) Received: from compute2.internal (compute2.nyi.mail.srv.osa [10.202.2.42]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id 74A8A208A4 for ; Tue, 17 Dec 2013 06:07:41 -0500 (EST) Received: from web6 ([10.202.2.216]) by compute2.internal (MEProxy); Tue, 17 Dec 2013 06:07:41 -0500 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= D0cuF8Kf/DKf4EX0dU9076ctHi8=; b=q1XmovjF3Ky2oNB4wplWRoVE5ev0NMeX i4ptBCzpn2kVdl5cMaunLcbfhK+XL31zEm1feGrfTzYHywssYFm/ipPu1mTZ7/q4 E1JYkofSncg3Uzmi6A8u3RRQASQ5z0HQcDveKRfyJFdvhmQcdoHSjkJylAAuZ2nJ KCByxgISEG0= 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=D0cuF8Kf/DKf4EX0dU9076ctHi8=; b=pd+zf ytzAxTUpE4eka8urKXI7NcVL0Z2NWf1vMuXoEz9eb/LzgkRblF7ajvvLHT7lxyln 1LshH4ycthjyM0C1M7/4gWalHfE1PT8tX5sU/lOHZ1+kJARv+3ZmrSlHh0KC6o91 Mkr+HctDva5JhncTU0H8g8N8hjYu+4/JA28Btk= Received: by web6.nyi.mail.srv.osa (Postfix, from userid 99) id 5DAE7285DC5; Tue, 17 Dec 2013 06:07:41 -0500 (EST) Message-Id: <1387278461.4079.60600749.1B5B4694@webmail.messagingengine.com> X-Sasl-Enc: F+w87ordg5/LSFd9Dw1WHcHl4FEk4MLOMTUHJipDe41o 1387278461 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-7f24e732 Date: Tue, 17 Dec 2013 22:07:41 +1100 In-Reply-To: <52AF4E01.9030600@isode.com> References: <20131216185040.21751.60172.idtracker@ietfa.amsl.com> <52AF4E01.9030600@isode.com> Subject: Re: [imapext] I-D Action: draft-ietf-qresync-rfc5162bis-05.txt X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Dec 2013 11:07:44 -0000 On Tue, Dec 17, 2013, at 06:01 AM, Alexey Melnikov wrote: > Hi everybody, > > On 16/12/2013 18:50, 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 Extensions for Conditional STORE Operation or Quick Flag Changes Resynchronization (CONDSTORE) and Quick Mailbox Resynchronization (QRESYNC) > > Author(s) : Alexey Melnikov > > Dave Cridland > > Filename : draft-ietf-qresync-rfc5162bis-05.txt > > Pages : 49 > > Date : 2013-12-16 > This version addresses all known issues (include 63-bit mod-sequences) > other than rewrite of the Abstract and the Introduction. The wording on the section I was concerned about looks good now. ...and there's nothing in here that would cause problems for what we're doing at FastMail now, where there's a single HIGHESTMODSEQ counter across all mailboxes, and the per-mailbox one just grabs that (+1) for a new per-mailbox HIGHESTMODSEQ when it makes any changes - meaning we can track a single value to know if there were changes anywhere for that user, and trigger a STATUS check. We're also using list extended syntax to get the STATUS fields in a single LIST command, which allows very fast resync - because we get an updated folder list each time as well, rather than pipelining STATUS commands for known folders. Bron. -- Bron Gondwana brong@fastmail.fm From alexey.melnikov@isode.com Tue Dec 17 14:11:13 2013 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 834821ADF0E for ; Tue, 17 Dec 2013 14:11:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.539 X-Spam-Level: X-Spam-Status: No, score=-2.539 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0QtLlPFtsD3m for ; Tue, 17 Dec 2013 14:11:12 -0800 (PST) Received: from waldorf.isode.com (waldorf.isode.com [62.3.217.251]) by ietfa.amsl.com (Postfix) with ESMTP id ED4161ADEC4 for ; Tue, 17 Dec 2013 14:11:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1387318270; d=isode.com; s=selector; i=@isode.com; bh=uIAUpdK7b7hYreOiRHzQjHjY3NyJ5u4GV9ByZEIZMWg=; 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=HWNOGViRxsG5omkp/2/sy6/qL//lTDXA4B3G9E9VHGicpYdLETYuyrRI6PhtFqXLG5x2IZ Lxqmv49Cx+JFS0G1SWjwkzy+43sCOuDOh+OlBZSAg5wQ/cgfytiFdHMhHP8PTjfKWVh1Wu +gWBq/aa78v0N0afLdzsGXEfN9dJsw4=; Received: from [192.168.0.4] (cpc5-nmal20-2-0-cust24.19-2.cable.virginm.net [92.234.84.25]) by waldorf.isode.com (submission channel) via TCP with ESMTPSA id ; Tue, 17 Dec 2013 22:11:10 +0000 X-SMTP-Protocol-Errors: PIPELINING Message-ID: <52B0CC02.7020700@isode.com> Date: Tue, 17 Dec 2013 22:11:14 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 To: Bron Gondwana References: <20131216185040.21751.60172.idtracker@ietfa.amsl.com> <52AF4E01.9030600@isode.com> <1387278461.4079.60600749.1B5B4694@webmail.messagingengine.com> In-Reply-To: <1387278461.4079.60600749.1B5B4694@webmail.messagingengine.com> 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-05.txt X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Dec 2013 22:11:13 -0000 On 17/12/2013 11:07, Bron Gondwana wrote: > On Tue, Dec 17, 2013, at 06:01 AM, Alexey Melnikov wrote: >> Hi everybody, >> >> On 16/12/2013 18:50, 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 Extensions for Conditional STORE Operation or Quick Flag Changes Resynchronization (CONDSTORE) and Quick Mailbox Resynchronization (QRESYNC) >>> Author(s) : Alexey Melnikov >>> Dave Cridland >>> Filename : draft-ietf-qresync-rfc5162bis-05.txt >>> Pages : 49 >>> Date : 2013-12-16 >> This version addresses all known issues (include 63-bit mod-sequences) >> other than rewrite of the Abstract and the Introduction. > The wording on the section I was concerned about looks good now. > > ...and there's nothing in here that would cause problems for what we're doing at > FastMail now, where there's a single HIGHESTMODSEQ counter across all mailboxes, > and the per-mailbox one just grabs that (+1) for a new per-mailbox HIGHESTMODSEQ > when it makes any changes - meaning we can track a single value to know if there > were changes anywhere for that user, and trigger a STATUS check. > > We're also using list extended syntax to get the STATUS fields in a single LIST > command, which allows very fast resync - because we get an updated folder list > each time as well, rather than pipelining STATUS commands for known folders. Sounds great. If you want to define an extra IMAP capability for server-wide MODSEQs, I can add it to the document. From internet-drafts@ietf.org Thu Dec 19 12:12:58 2013 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF7CA1AE720; Thu, 19 Dec 2013 12:12:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t7ONTieg-hSQ; Thu, 19 Dec 2013 12:12:57 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A1521AE71C; Thu, 19 Dec 2013 12:12:57 -0800 (PST) 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.84 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131219201257.31800.9567.idtracker@ietfa.amsl.com> Date: Thu, 19 Dec 2013 12:12:57 -0800 Cc: imapext@ietf.org Subject: [imapext] I-D Action: draft-ietf-qresync-rfc5162bis-06.txt X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.15 List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Dec 2013 20:12: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 Extensions for Conditional STORE Operation or Quick= Flag Changes Resynchronization (CONDSTORE) and Quick Mailbox Resynchroniza= tion (QRESYNC) Author(s) : Alexey Melnikov Dave Cridland Filename : draft-ietf-qresync-rfc5162bis-06.txt Pages : 49 Date : 2013-12-19 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. The Conditional Store facility allows a client to quickly resynchronize mailbox flag changes. The Conditional Store facility also provides a protected update mechanism for message state information that can detect and resolve conflicts between multiple writing mail clients. For example, the mechanism can be used to guarantee that only one client can change message state at any time. This document additionally defines another IMAP extension, which gives an IMAP client the ability to quickly resynchronize any previously opened mailbox as part of the SELECT/EXAMINE command, without the need for server-side state or additional client round- trips. That extension builds on top of the Conditional Store extension and covers message deletions in addition to flag changes. 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-06 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-qresync-rfc5162bis-06 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/