From dave@cridland.net Wed May 8 08:30:06 2013 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A893121F92F7 for ; Wed, 8 May 2013 08:30:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.976 X-Spam-Level: X-Spam-Status: No, score=-1.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ku4rhSuY1UeO for ; Wed, 8 May 2013 08:30:06 -0700 (PDT) Received: from mail-wi0-x232.google.com (mail-wi0-x232.google.com [IPv6:2a00:1450:400c:c05::232]) by ietfa.amsl.com (Postfix) with ESMTP id AB46D21F9026 for ; Wed, 8 May 2013 08:30:05 -0700 (PDT) Received: by mail-wi0-f178.google.com with SMTP id hm14so2064814wib.11 for ; Wed, 08 May 2013 08:30:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cridland.net; s=google; h=x-received:content-type:mime-version:subject:x-mailer:date :message-id:from:to:cc; bh=E5qwNnwOBkGKUMgbXkiXqV3J3sPxJMK3BoOOZWPzNmo=; b=YijzDAo7Tv1OujQGPgy1s3kuEj/dvuS7c6ULHKFvsyh80ofaOSgS/xdSbeFBHeIlPD qwxlftXqnZFde1MzBwczvFa+Kcy20s32yb70rAlcC20k/VKi/XhrGZQIVD8jUKb8yKvK TUBHzrUAbHpNQCE0IBUh+mChNDhtqmq/weHsQ= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:content-type:mime-version:subject:x-mailer:date :message-id:from:to:cc:x-gm-message-state; bh=E5qwNnwOBkGKUMgbXkiXqV3J3sPxJMK3BoOOZWPzNmo=; b=OCCG7Emgrc5ANgmr4ORRIMK3dcwpluqacpbow6uFJ+aPoReYHj3xxkcT4bb5TPdWEK 14FXjl8iltL0Ik8m+2PgruK2s931g55C4EJhALygpQ216NYdN9tV5wRZjPw+Jeggyx4H n8v0m60Hn10CTHk5ZB/EyEkLdDbwl4qPshT0Ow2ItpgBuU10FdgnLWrKZ4m/1GYXeWpa zCe7PKRFIMiKmiz2W17gktYI8o1m9SJCqBThWY2KFSL5gsL16WTvYfb3UPgBCJQzCQUT 97Oyj9ZHHY/KpfV+EtB1efHe9NlSesFiEgmySIihnORjiTXvi1nRlsbYqEMwoyxjOOsF vsDg== X-Received: by 10.194.76.199 with SMTP id m7mr11735599wjw.43.1368027004362; Wed, 08 May 2013 08:30:04 -0700 (PDT) Received: from Sputnik.dave.cridland.net (invsysm1.dave.cridland.net. [217.155.137.57]) by mx.google.com with ESMTPSA id bs20sm9961953wib.0.2013.05.08.08.30.01 for (version=TLSv1.1 cipher=RC4-SHA bits=128/128); Wed, 08 May 2013 08:30:03 -0700 (PDT) Content-Type: multipart/alternative; boundary="===============0800175524==" MIME-Version: 1.0 X-Mailer: Inky (TM) v1.0.518A.5B37 ("Epoch") Date: Wed, 08 May 2013 15:29:59 -0000 Message-Id: From: Dave Cridland To: "imapext@ietf.org" Cc: X-Gm-Message-State: ALoCoQlLxmZlVrC4btU3ZhWmyJ76pG5krn1RA/qZ2fjUk5Cwktjgdbyt4T51eGk2EqZqXJl9vV+N Subject: [imapext] qresync WG kick-off X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 May 2013 15:30:06 -0000 --===============0800175524== Content-Type: text/plain; charset="iso-8859-1" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable As chairman. Just so everyone's on the same page, the plan for the working group is essentially as follows: - Alexey's putting together starting drafts, which we'll be looking to adopt. - Once those drafts are out, we'll need reviewers on them to gauge what milestones we should have - we currently just have a publication request milestone of December; Eliot and I suspect this could be moved much sooner if we feel that the issues are well-known. - We're not intending meeting. This includes online meetings - all discussion will therefore be solely on this list. Just to refresh your memories, all discussion on this list (working- group related or not) is covered by the Note Well; if you're unclear what your responsibilities are under this, please ask. Sent with [inky: ] --===============0800175524== Content-Type: text/html; charset="iso-8859-1" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable

As chairman.

=A0

Just so everyone's on the same page, the plan for the working group is es= sentially as follows:

=A0

- Alexey's putting together starting drafts, which we'll be looking to ad= opt.

- Once those drafts are out, we'll need reviewers on them to gauge what m= ilestones we should have - we currently just have a publication request mil= estone of December; Eliot and I suspect this could be moved much sooner if = we feel that the issues are well-known.

- We're not intending meeting. This includes online meetings - all discus= sion will therefore be solely on this list.

=A0

Just to refresh your memories, all discussion on this list (working-group= related or not) is covered by the Note Well; if you're unclear what your r= esponsibilities are under this, please ask.

=A0

Sent with=A0inky

=A0

--===============0800175524==-- From jkt@flaska.net Thu May 9 09:27:47 2013 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF8F321F86D5 for ; Thu, 9 May 2013 09:27:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.1 X-Spam-Level: X-Spam-Status: No, score=-1.1 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_64=0.6, J_CHICKENPOX_74=0.6, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zqcZqsxIc1nv for ; Thu, 9 May 2013 09:27:47 -0700 (PDT) Received: from latimerie.flaska.net (latimerie.flaska.net [IPv6:2a02:2b88:2:1::4a7:333]) by ietfa.amsl.com (Postfix) with ESMTP id 0027A21F86C1 for ; Thu, 9 May 2013 09:27:46 -0700 (PDT) Received: by latimerie.flaska.net (Postfix, from userid 1000) id 1E05A60A1B; Thu, 9 May 2013 18:27:43 +0200 (CEST) From: =?iso-8859-1?Q?Jan_Kundr=E1t?= To: Date: Thu, 09 May 2013 18:27:43 +0200 User-Agent: trojita/v0.3.93-15-g2be0e57; Qt/4.8.4; X11; Linux; MIME-Version: 1.0 Message-ID: <05c6cf93-2e5e-469d-b356-0751f2bdd5df@flaska.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Subject: [imapext] GMail's extensions: X-GM-THRID immutability X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 May 2013 16:27:48 -0000 Hi,=0Athis might be a bit OT for this mailing list, but given that GMai= l is a rather dominant player among the IMAP service providers and due = to the usefulness of having data available to other, I'm posting here a= nyway.=0A=0A- It isn't clear to me what the immutability guarantees of = the returned data of the X-GM-THRID [1] extension are. It would be terr= ific if it was safe to cache these values in the same manner as any oth= er immutable per-message data, but I suspect this is not possible -- if= the threading is "right", delivery of any new message could potentiall= y join independent threads together, thereby changing the thread IDs. H= ow is GMail handling this? How is the threading computed?=0A=0A- Any pl= ans to support the THREAD=3DREFS [2] in GMail?=0A=0A- Any plans for sup= port of the SORT extensions?=0A=0A- Any plans for CONTEXT=3DSORT and CO= NTEXT=3DSEARCH? :)=0A=0AThe reason why I'm asking is because I'd like t= o enable threading for Trojita's users who are accessing GMail. Any thr= eading algorithm apart from THREAD=3DREFS has significant limitations w= ithout a server-side sorting simply because old threads with new arriva= ls are not listed as recent. The only remedy is giving up and hoping th= at UIDs somehow correlate with the age of a any message, which is rathe= r crude heuristic.=0A=0AWith kind regards,=0AJan=0A=0A[1] https://devel= opers.google.com/google-apps/gmail/imap_extensions#access_to_the_gmail_= thread_id_x-gm-thrid=0A[2] http://tools.ietf.org/html/draft-ietf-morg-i= nthread-01=0A=0A-- =0ATrojit=C3=A1, a fast Qt IMAP e-mail client -- htt= p://trojita.flaska.net/ From alexey.melnikov@isode.com Thu May 9 12:35:38 2013 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 606D221F8F6E for ; Thu, 9 May 2013 12:35:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.953 X-Spam-Level: X-Spam-Status: No, score=-100.953 tagged_above=-999 required=5 tests=[AWL=-0.654, BAYES_00=-2.599, MANGLED_TOOL=2.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aHPjZvFosXZ7 for ; Thu, 9 May 2013 12:35:34 -0700 (PDT) Received: from statler.isode.com (statler.isode.com [62.3.217.254]) by ietfa.amsl.com (Postfix) with ESMTP id 0567821F8F4D for ; Thu, 9 May 2013 12:35:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1368128132; d=isode.com; s=selector; i=@isode.com; bh=ELKRUffC938KBU34/aVX5Nd7wpOP45/4p2tt0MxSLNY=; 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=m7ttZMKFZ9pQL1v6aYJRtSfOQ9cbwvfZH5mkE2g8UU3WvneEhRs+wQVIRGuqhh5dKvgVhs adbs8QxiNKpvtvaY7uHDzRLcyIno9NDYJ+DZyhQjL6V0OK8WUtmxA9/UojBihNc4E1SMhV fxsU/OzYkA1NYVNKk99e6eJPSffEn6s=; Received: from [172.16.1.29] (shiny.isode.com [62.3.217.250]) by statler.isode.com (submission channel) via TCP with ESMTPA id ; Thu, 9 May 2013 20:35:32 +0100 Message-ID: <518BFA87.8080209@isode.com> Date: Thu, 09 May 2013 20:35:35 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 To: Dave Cridland References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "imapext@ietf.org" Subject: Re: [imapext] qresync WG kick-off X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 May 2013 19:35:38 -0000 On 08/05/2013 16:29, Dave Cridland wrote: > > As chairman. > > Just so everyone's on the same page, the plan for the working group is > essentially as follows: > > - Alexey's putting together starting drafts, which we'll be looking to > adopt. > Actually no, I think the WG should look at adopting http://datatracker.ietf.org/doc/draft-melnikov-5162bis/ List of changes for the current version (-01) is: Appendix A. Changes since RFC 5162 Addressed erratum #1365: http://www.rfc-editor.org/errata_search.php?eid=1365 Addressed erratum #1807: http://www.rfc-editor.org/errata_search.php?eid=1807 Addressed erratum #1808: http://www.rfc-editor.org/errata_search.php?eid=1808 Addressed erratum #1809: http://www.rfc-editor.org/errata_search.php?eid=1809 Addressed erratum #3322: http://www.rfc-editor.org/errata_search.php?eid=3322 Fixed some examples to report data that match requirements specified Obviously the WG (once the draft is adopted by the WG) can decide to address these issues differently, but for now I assume that they are adequately addressed. I don't have any pending changes to -01. I do have a list of pending issues though, which I can post here. > - Once those drafts are out, we'll need reviewers on them to gauge > what milestones we should have - we currently just have a publication > request milestone of December; Eliot and I suspect this could be moved > much sooner if we feel that the issues are well-known. > > - We're not intending meeting. This includes online meetings - all > discussion will therefore be solely on this list. > > Just to refresh your memories, all discussion on this list > (working-group related or not) is covered by the Note Well; if you're > unclear what your responsibilities are under this, please ask. > From alexey.melnikov@isode.com Thu May 9 12:39:53 2013 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1E2321F8E2C for ; Thu, 9 May 2013 12:39:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.776 X-Spam-Level: X-Spam-Status: No, score=-101.776 tagged_above=-999 required=5 tests=[AWL=0.823, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5RAjAjd211Ne for ; Thu, 9 May 2013 12:39:47 -0700 (PDT) Received: from statler.isode.com (statler.isode.com [62.3.217.254]) by ietfa.amsl.com (Postfix) with ESMTP id 90B0F21F8E6B for ; Thu, 9 May 2013 12:39:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1368128386; d=isode.com; s=selector; i=@isode.com; bh=eACuwITSEBcSYPEkmLIl2G6BYboAAORdGlqLSgNePck=; 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=cBVWyugrDZ1r1PwvuIB2XZKbSWkTqkehNf+WyL9qohVQcHG+weL6oFc3MaYlm7OrHe3yXa /XVgoFa+GvLYeB2K/kmKx7491oHgJrwt6wGOZ0y2BkpCXA30U8ukhodmgCn8EW6eerWsVK E99IeGnTnGSeOcJlRe+GvNSL7kBOWpY=; Received: from [172.16.1.29] (shiny.isode.com [62.3.217.250]) by statler.isode.com (submission channel) via TCP with ESMTPA id ; Thu, 9 May 2013 20:39:46 +0100 Message-ID: <518BFB86.6000808@isode.com> Date: Thu, 09 May 2013 20:39:50 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 To: Dave Cridland References: <518BFA87.8080209@isode.com> In-Reply-To: <518BFA87.8080209@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] qresync WG kick-off X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 May 2013 19:39:54 -0000 On 09/05/2013 20:35, Alexey Melnikov wrote: > On 08/05/2013 16:29, Dave Cridland wrote: >> >> As chairman. >> >> Just so everyone's on the same page, the plan for the working group >> is essentially as follows: >> >> - Alexey's putting together starting drafts, which we'll be looking >> to adopt. > Actually no, I think the WG should look at adopting > http://datatracker.ietf.org/doc/draft-melnikov-5162bis/ I will be working on a CONDSTORE draft next week. Are chairs Ok with accepting 1 draft at a time? From blong@google.com Thu May 9 14:53:46 2013 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D37921F8F27 for ; Thu, 9 May 2013 14:53:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.211 X-Spam-Level: X-Spam-Status: No, score=-98.211 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_64=0.6, J_CHICKENPOX_65=0.6, J_CHICKENPOX_74=0.6, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001, SARE_HTML_USL_OBFU=1.666, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9EFERpTqv7Qa for ; Thu, 9 May 2013 14:53:45 -0700 (PDT) Received: from mail-qa0-x229.google.com (mail-qa0-x229.google.com [IPv6:2607:f8b0:400d:c00::229]) by ietfa.amsl.com (Postfix) with ESMTP id C4F3F21F8F17 for ; Thu, 9 May 2013 14:53:44 -0700 (PDT) Received: by mail-qa0-f41.google.com with SMTP id bv4so22875qab.14 for ; Thu, 09 May 2013 14:53:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=0S9HVNrPRRlokMUc19PxRtSCFpdg1uIOn1kP1zlVFuI=; b=H+cZ/fFdjvSIA2bghcBrVhLWi4Ns1aUcLh85VYoS7NL/Qgtj4TWDigIl56Oqstd8y1 5Ti/KgxszbIQ84/zdOwg1LmGtzX2bZsG20y221Wv9ATv1EEX410kSxzJ63EShbzg+eT1 DRHW6GM7OsSJvfvmKj1jJjCNMDyrmzl23mpI0HdJcqsUWqWv48MDxaZfRLT5T6zQs/X6 VsWfM8YxMDyr/YW7teX54ZEzblvY5sEAUpCixqvdkFODIRGCiQAP4e8m6FAonypM/nkF 2UKE9l8e8wkwmY7uU3yIKIv6NIAd7ab+TDNmwzRqp8leI4aT/u+iTlkEJc+s9z+c5m8I qIfg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=0S9HVNrPRRlokMUc19PxRtSCFpdg1uIOn1kP1zlVFuI=; b=VcCVP6OGEOsec3fi5D4fruLFpFQtc52EsaSa39vjajAdp2NhGr3qlTyA8l+xzqtMuQ ZGquYIlHoJB40/AdKxZ3T1RDL7w45K1f1EaubHVQTyT4e0H/o6VOb7Eb22eye+Yia6+U L6vCfRqDBGQqT0etNfC19mjdzttEElm3gTDo11M1Az5UwW/K3fqGGZ9qMLHtmVoZgz7U hD6qBofUl+mpkDvkzJWd8Aiu2OLP9OYQ9UL2glegQZSw8Lq8uSgt0Uwq34NNw03kzaTO 9qC/5lgZyES2Qk7ph0Fl8/G8yIZW2vu/LOSgCgyP/jE7O8uraUT4jnzlr7+OhGLM3ezO 9Q8A== MIME-Version: 1.0 X-Received: by 10.49.3.6 with SMTP id 6mr11074723qey.64.1368136424170; Thu, 09 May 2013 14:53:44 -0700 (PDT) Received: by 10.229.92.145 with HTTP; Thu, 9 May 2013 14:53:44 -0700 (PDT) In-Reply-To: <05c6cf93-2e5e-469d-b356-0751f2bdd5df@flaska.net> References: <05c6cf93-2e5e-469d-b356-0751f2bdd5df@flaska.net> Date: Thu, 9 May 2013 14:53:44 -0700 Message-ID: From: Brandon Long To: =?ISO-8859-1?Q?Jan_Kundr=E1t?= Content-Type: multipart/alternative; boundary=047d7bdc0aba916f3c04dc5015b0 X-Gm-Message-State: ALoCoQlhBBn9bWG/g5vovB4s5PCU8keCMUOqOW0EdHTBCKA5Zd3aQNJ5z9yrKdBUcIvUwalIJ7gyVqnIJnGLCbUEnt30b4JvFAOTuC/0XPFA5NjeipHr+Eq8ZVQ7M5O8qhYcfYiYxI6k6iMHk1seD9AAP3aJ0XmqrzK2TZ4LC13IV1QujaAcfG3oEG0Xgn07M2VBAVFIFHHN Cc: "imapext@ietf.org" Subject: Re: [imapext] GMail's extensions: X-GM-THRID immutability X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 May 2013 21:53:46 -0000 --047d7bdc0aba916f3c04dc5015b0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Thu, May 9, 2013 at 9:27 AM, Jan Kundr=E1t wrote: > Hi, > this might be a bit OT for this mailing list, but given that GMail is a > rather dominant player among the IMAP service providers and due to the > usefulness of having data available to other, I'm posting here anyway. > > - It isn't clear to me what the immutability guarantees of the returned > data of the X-GM-THRID [1] extension are. It would be terrific if it was > safe to cache these values in the same manner as any other immutable > per-message data, but I suspect this is not possible -- if the threading = is > "right", delivery of any new message could potentially join independent > threads together, thereby changing the thread IDs. How is GMail handling > this? How is the threading computed? > You should be able to consider X-GM-THRID as immutable, that should have been called out in the documents. We never join threads. Gmail does not thread by references, its closest to threading by subject. Our user facing parlance is typically "conversation" instead of thread. A conversation is basically up to 100 messages with the same "clean" subject. IIRC, we will start a new conversation if there is sufficient time gap between the two, but we will use references to put a reply on an old conversation regardless of time... though the 100 message is a "hard" limit= . Having a limit was chosen for performance reasons, we don't want to load a couple thousand message indexes from disk or have paging in the conversation view interface. The conversation view doesn't lend itself to true threading either, where "new" messages may be in multiple places in the page.... and most email communication doesn't have that complicated of a thread structure to begin with. It also fixes the typical use cases of "find a message from foo and reply and change the subject" instead of using an address book and some other corner cases. > > - Any plans to support the THREAD=3DREFS [2] in GMail? > So, the new search terms might be interesting. MESSAGEID is basically how we handle HEADER MESSAGEID already (ie, its not substring, its actually mapped to the rfc822messageid: term in our index). INTHREAD is more odd because our threads can cross folder boundaries (since they're not folders, they're labels) but nothing overly complicated for us. THREAD=3DREFS is just as unlikely as THREAD=3DREFERENCES for us. We're not computing threads on the fly just for IMAP. We had one early engineer on the project joke about implementing THREAD=3DGMAIL, but the THREAD=3D conce= pt seems fundamentally flawed to me that both the client and server require understanding of the threading algorithm. X-GM-THRID is basically "the server knows the threads, trust it". > - Any plans for support of the SORT extensions? > We have only the single SORT order in everything we do, so no. Again, we can't load the entire folder into memory just to SORT it on the server, and we're not going to pre-compute and store each possible order. You'll note there is only the one order in all of the Gmail interfaces. Our marketing would say, don't sort, search! > - Any plans for CONTEXT=3DSORT and CONTEXT=3DSEARCH? :) > No. We'd probably have to create a filter on the fly for CONTEXT=3DSEARCH, get updates that the filter has hit, and then load and finish testing against the new message to see if it actually hit (not all of the IMAP SEARCH syntax is translatable to our own search syntax, some things require loading parts of the message). That just seems like an overall large effort for supporting "online" low caching clients, and we don't really support them well in many other ways, mostly because almost all clients are actually offline caching clients. > > The reason why I'm asking is because I'd like to enable threading for > Trojita's users who are accessing GMail. Any threading algorithm apart fr= om > THREAD=3DREFS has significant limitations without a server-side sorting > simply because old threads with new arrivals are not listed as recent. Th= e > only remedy is giving up and hoping that UIDs somehow correlate with the > age of a any message, which is rather crude heuristic. > What does "old thread with new arrivals are not listed as recent" mean? New messages are clearly new, since they have newer UIDs (well, new to that folder at least). We always display messages in our "threads" in INTERNALDATE order. Brandon > > With kind regards, > Jan > > [1] https://developers.google.com/**google-apps/gmail/imap_** > extensions#access_to_the_**gmail_thread_id_x-gm-thrid > [2] http://tools.ietf.org/html/**draft-ietf-morg-inthread-01 > > -- > 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 > --047d7bdc0aba916f3c04dc5015b0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Thu, May 9, 2013 at 9:27 AM, Jan Kundr=E1t <= ;jkt@flaska.net>= wrote:
Hi,
this might be a bit OT for this mailing list, but given that GMail is a rat= her dominant player among the IMAP service providers and due to the usefuln= ess of having data available to other, I'm posting here anyway.

- It isn't clear to me what the immutability guarantees of the returned= data of the X-GM-THRID [1] extension are. It would be terrific if it was s= afe to cache these values in the same manner as any other immutable per-mes= sage data, but I suspect this is not possible -- if the threading is "= right", delivery of any new message could potentially join independent= threads together, thereby changing the thread IDs. How is GMail handling t= his? How is the threading computed?

You should be able to consider X-GM-= THRID as immutable, that should have been called out in the documents. =A0W= e never join threads.

Gmail does not t= hread by references, its closest to threading by subject. =A0Our user facin= g parlance is typically "conversation" instead of thread. =A0A co= nversation is basically up to 100 messages with the same "clean" = subject. =A0IIRC, we will start a new conversation if there is sufficient t= ime gap between the two, but we will use references to put a reply on an ol= d conversation regardless of time... though the 100 message is a "hard= " limit.

Having a limit was chosen for performance r= easons, we don't want to load a couple thousand message indexes from di= sk or have paging in the conversation view interface. =A0The conversation v= iew doesn't lend itself to true threading either, where "new"= messages may be in multiple places in the page.... and most email communic= ation doesn't have that complicated of a thread structure to begin with= . =A0It also fixes the typical use cases of "find a message from foo a= nd reply and change the subject" instead of using an address book and = some other corner cases.
=A0

- Any plans to support the THREAD=3DREFS [2] in GMail?

So, the new search terms might be interesting. =A0MES= SAGEID is basically how we handle HEADER MESSAGEID already (ie, its not sub= string, its actually mapped to the rfc822messageid: term in our index). =A0= INTHREAD is more odd because our threads can cross folder boundaries (since= they're not folders, they're labels) but nothing overly complicate= d for us.

THREAD=3DREFS is just as unlikely as THREAD= =3DREFERENCES for us. =A0We're not computing threads on the fly just fo= r IMAP. =A0We had one early engineer on the project joke about implementing= THREAD=3DGMAIL, but the THREAD=3D concept seems fundamentally flawed to me= that both the client and server require understanding of the threading alg= orithm. =A0X-GM-THRID is basically "the server knows the threads, trus= t it".
=A0
- Any plans for support of the SORT extensions?

We have only the single SORT order in everything we do, so n= o. =A0Again, we can't load the entire folder into memory just to SORT i= t on the server, and we're not going to pre-compute and store each poss= ible order. =A0You'll note there is only the one order in all of the Gm= ail interfaces. =A0Our marketing would say, don't sort, search!
=A0
- Any plans for CONTEXT=3DSORT and CONTEXT=3DSEARCH? :)

No. =A0We'd probably have to create a filter on = the fly for CONTEXT=3DSEARCH, get updates that the filter has hit, and then= load and finish testing against the new message to see if it actually hit = (not all of the IMAP SEARCH syntax is translatable to our own search syntax= , some things require loading parts of the message). =A0That just seems lik= e an overall large effort for supporting "online" low caching cli= ents, and we don't really support them well in many other ways, mostly = because almost all clients are actually offline caching clients.
=A0

The reason why I'm asking is because I'd like to enable threading f= or Trojita's users who are accessing GMail. Any threading algorithm apa= rt from THREAD=3DREFS has significant limitations without a server-side sor= ting simply because old threads with new arrivals are not listed as recent.= The only remedy is giving up and hoping that UIDs somehow correlate with t= he age of a any message, which is rather crude heuristic.

What does "old thread with new = arrivals are not listed as recent" mean? =A0New messages are clearly n= ew, since they have newer UIDs (well, new to that folder at least). =A0We a= lways display messages in our "threads" in INTERNALDATE order.

Brandon
=A0

With kind regards,
Jan

[1] https://dev= elopers.google.com/google-apps/gmail/imap_extensions#access_t= o_the_gmail_thread_id_x-gm-thrid
[2] http://tools.ietf.org/html/draft-ietf-morg-inthread-01=

--
Trojit=E1, a fast Qt IMAP e-mail client -- http://trojita.flaska.net/
_______________________________________________
imapext mailing list
imapext@ietf.org<= br> https://www.ietf.org/mailman/listinfo/imapext

--047d7bdc0aba916f3c04dc5015b0-- From jkt@flaska.net Fri May 10 03:51:10 2013 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89C2721F8B49 for ; Fri, 10 May 2013 03:51:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.4 X-Spam-Level: X-Spam-Status: No, score=-1.4 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, J_CHICKENPOX_64=0.6, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oBClA-vqg81A for ; Fri, 10 May 2013 03:51:08 -0700 (PDT) Received: from latimerie.flaska.net (latimerie.flaska.net [IPv6:2a02:2b88:2:1::4a7:333]) by ietfa.amsl.com (Postfix) with ESMTP id 81CF721F86F7 for ; Fri, 10 May 2013 03:51:06 -0700 (PDT) Received: by latimerie.flaska.net (Postfix, from userid 1000) id 7B69A604AB; Fri, 10 May 2013 12:51:01 +0200 (CEST) From: =?iso-8859-1?Q?Jan_Kundr=E1t?= To: Date: Fri, 10 May 2013 12:51:02 +0200 User-Agent: trojita/v0.3.93-15-g2be0e57; Qt/4.8.4; X11; Linux; MIME-Version: 1.0 Message-ID: In-Reply-To: References: <05c6cf93-2e5e-469d-b356-0751f2bdd5df@flaska.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Subject: [imapext] Re: GMail's extensions: X-GM-THRID immutability X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 May 2013 10:51:10 -0000 On Thursday, 9 May 2013 23:53:44 CEST, Brandon Long wrote:=0A> You shou= ld be able to consider X-GM-THRID as immutable, that should have=0A> be= en called out in the documents. We never join threads.=0A=0AThanks, th= is answers my question perfectly.=0A=0A> but the THREAD=3D concept=0A> = seems fundamentally flawed to me that both the client and server requir= e=0A> understanding of the threading algorithm.=0A=0ACould you elaborat= e a bit? Trojita does not have any builtin knowledge of any threading a= lgorithm, yet will happily issue and use THREAD=3D{REFS,REFERENCES,ORDE= REDSUBJECT} and display the result to the user. It works pretty well, a= ctually. Best when combined with Dovecot due to its THREAD=3DREFS suppo= rt.=0A=0AYes, this means that upon an arrival of a new message, it has = to ask for the threading info for a whole mailbox again simply because = we might not know the Message-Id of the existing threads, and therefore= cannot replicate the server's algorithm. This is the "joy" of lazy loa= ding in action :(.=0A=0AI've tried to address this waste of bandwidth b= y the INCTHREAD proposal [1], but I didn't have time to push for its in= clusion in FLOSS IMAP servers yet.=0A=0A> What does "old thread with ne= w arrivals are not listed as recent" mean?=0A=0ATHREAD=3DREFERENCES and= THREAD=3DORDEREDSUBJECT both sort the list of threads by the INTERNALD= ATE of the thread root. Trojita will always display the threads in the = order in which the THREAD response contained them. This means that an o= ld thread which receives a new response will still be listed midway thr= ough the list of all threads, not at the end. Effectively, this means t= hat these algorithms are rather useless for a client which wants to rel= y on server-side threading.=0A=0ASituation is much better with THREAD=3D= REFS because the threads are sorted by the most recent message in asubt= hread, not by the timestamp of the thread root. When a new message arri= ves, the whole thread is brought to the end of the THREAD response and = the client knows that it shall be shown as a recent one.=0A=0AIn Trojit= a, the ENVELOPE and INTERNALDATE are lazily loaded, fetched only for cu= rrently visible messages (with some preload). We don't fetch these for = each message in a 100k mailbox for obvious reasons. However, this means= that we cannot reliably post-process the THREAD response by sorting th= e threads according to the latest message in them.=0A=0A> New messages = are clearly new, since they have newer UIDs (well, new to=0A> that fold= er at least).=0A=0AThat's a good heuristic, thanks for suggesting that.= It breaks when I copy/move and old thread from my INBOX into some spec= ific mailbox -- even though the new mailbox probably contains newer mes= sages, the old thread would be displayed at the end, among the recent o= nes, due to the higher UIDs. Still, I agree that it's better than havin= g truly new messages sunk deep withing the mailbox history. I'll have a= look at implementing this for algorithms other than THREAD=3DREFS.=0A=0A= > We always display messages in our "threads" in INTERNALDATE order.=0A= =0AI agree that this is (or at least *should*) be the only useful sort = order. I tend to agree with your marketing department in thinking that = sorting by e.g. the sender in order to find messages from a particular = person is, well, dumb.=0A=0ADo you handle the INTERNALDATE in conforman= ce with the SHOULDs in RFC3501 (i.e. they don't have to correlate with = the order of UIDs, but truly reflect the arrival of the message *to you= r server*, not to a *mailbox*)? Do you also sort the "threads" themselv= es according to the INTERNALDATE of the newest message in each thread? = If so, could you make *this* feature available over IMAP? I don't care = for being able to sort by sender or subject, but I do care for being ab= le to reliably show truly recent messages at the bottom (or top) of the= view.=0A=0AWith kind regards,=0AJan=0A=0A[1] http://tools.ietf.org/htm= l/draft-kundrat-incthread-01=0A=0A-- =0ATrojit=C3=A1, a fast Qt IMAP e-= mail client -- http://trojita.flaska.net/ From arnt@gulbrandsen.priv.no Fri May 10 09:02:09 2013 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6EB9F21F8E6E for ; Fri, 10 May 2013 09:02:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ApQBdo6-Q7Fy for ; Fri, 10 May 2013 09:02:08 -0700 (PDT) Received: from strange.aox.org (strange.aox.org [IPv6:2001:4d88:100c::1]) by ietfa.amsl.com (Postfix) with ESMTP id 43DAE21F8EE1 for ; Fri, 10 May 2013 09:02:06 -0700 (PDT) Received: from fri.gulbrandsen.priv.no (localhost [127.0.0.1]) by strange.aox.org (Postfix) with ESMTP id 6F24FFA00E6; Fri, 10 May 2013 16:02:05 +0000 (UTC) Received: from arnt@gulbrandsen.priv.no by fri.gulbrandsen.priv.no (Archiveopteryx 3.1.4) with esmtpsa id 1368201724-1635-1633/11/1; Fri, 10 May 2013 16:02:04 +0000 User-Agent: Kaiten Mail In-Reply-To: References: <05c6cf93-2e5e-469d-b356-0751f2bdd5df@flaska.net> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=----6VM36WBXZDWR7YX8PASMYHSCDLJWXK From: Arnt Gulbrandsen Date: Fri, 10 May 2013 18:02:01 +0200 To: imapext@ietf.org Message-Id: <87cbc15a-2079-4401-abc1-f6938df543d1@email.android.com> Subject: Re: [imapext] GMail's extensions: X-GM-THRID immutability X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 May 2013 16:02:09 -0000 ------6VM36WBXZDWR7YX8PASMYHSCDLJWXK Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Refs can be computed at delivery time. You have to sort the lines at = read time, that is all. Arnt ------6VM36WBXZDWR7YX8PASMYHSCDLJWXK Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

Refs can be computed at delivery time. You have to sort the = lines at read time, that is all.


Arnt ------6VM36WBXZDWR7YX8PASMYHSCDLJWXK-- From blong@google.com Fri May 10 13:41:55 2013 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8980221F90BB for ; Fri, 10 May 2013 13:41:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.144 X-Spam-Level: X-Spam-Status: No, score=-100.144 tagged_above=-999 required=5 tests=[AWL=1.933, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_64=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gkF-HtL-uTOM for ; Fri, 10 May 2013 13:41:50 -0700 (PDT) Received: from mail-qe0-f46.google.com (mail-qe0-f46.google.com [209.85.128.46]) by ietfa.amsl.com (Postfix) with ESMTP id E090621F881C for ; Fri, 10 May 2013 13:41:49 -0700 (PDT) Received: by mail-qe0-f46.google.com with SMTP id f6so2740580qej.33 for ; Fri, 10 May 2013 13:41:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=ni4OlwrbwJRPeWndwFxiWMmJqkCRniXfKvAxQnGv1j8=; b=PrLOtWT/ldsCJ12Qm7r+71smZfGcACZw87CN5ds45GdQjzztqmabC3QMC3YUrFZ0iF bI7s9OGtCG8VZg61m6MER2puUBs0OEY9NNCLdIRwPKJsAs01TBOAdJMUrxZDWLOKEVCr m4vyBY4i1PO1pCuidhAGN04iZDevM7tKgfUIVbJ0/0YGUawRxD8r9M4USAGWl75BOHLU nuQgyMOgyrhPyCoEDLKvbI+DlrdXS2EFy0I448S6OYBB9ncKxDgl21qX4j+Gl9NbST9B fJ7ppi1xrcPf25YwBriTQizP41BDjmVABwFzfmm637yNjoAAeiaVSJ3p84SXUsWTVvMa lUEw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=ni4OlwrbwJRPeWndwFxiWMmJqkCRniXfKvAxQnGv1j8=; b=hHVuGJHvNnUTiQDcBL9xqEKIQBzqado6hf2rniN14aSzr43m3ByLeeVw7L373RTNr0 vA2qIBOfEm9DbR/HlXo/Q82lr7tJpP/8rDjrf4fpNqJZAZpVoPyvsLlhyIi6cGGldYsk i4eipXNjz4rj9Z2ahXoelHODvaHfREgRZizXdy1AZGLGKMR54xFVYnhJkioIH4IAcbVv OJPWLWO0zoLgzUT1lukTXAOstEYCJkDoamYVmF585hPsbH5W1m1j9NzrN6Pp7VnaYlK/ cSm1rd/Ay/azSotbcCVvUpV30A0r555wOHnM8efaRcXxltxJowP5L3s4OHaMP+QLkp6Z coWQ== MIME-Version: 1.0 X-Received: by 10.224.93.15 with SMTP id t15mr6943938qam.71.1368218509334; Fri, 10 May 2013 13:41:49 -0700 (PDT) Received: by 10.229.92.145 with HTTP; Fri, 10 May 2013 13:41:49 -0700 (PDT) In-Reply-To: References: <05c6cf93-2e5e-469d-b356-0751f2bdd5df@flaska.net> Date: Fri, 10 May 2013 13:41:49 -0700 Message-ID: From: Brandon Long To: =?ISO-8859-1?Q?Jan_Kundr=E1t?= Content-Type: multipart/alternative; boundary=089e0153728c39ad9804dc633227 X-Gm-Message-State: ALoCoQkt+cpFyZ9e1g2FfDUNfJhdHBYc6ONtOgWP6nQp51trhiGwGCgBc/1bSBbxGsFDGdcSkB8khgpz/F5c/OhXdgC2iUyYAtmst0+rr7ZbOG/RaPIN9WrYQ2K1p/7QWkljpj16ebvw0y4PrzUQc7ypOc7fMUZahMQQf6RPUqXbRfIxtT2HV5AfPqt50X5aUFYp3mSeFzd3 Cc: "imapext@ietf.org" Subject: Re: [imapext] GMail's extensions: X-GM-THRID immutability X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 May 2013 20:41:55 -0000 --089e0153728c39ad9804dc633227 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Fri, May 10, 2013 at 3:51 AM, Jan Kundr=E1t wrote: > On Thursday, 9 May 2013 23:53:44 CEST, Brandon Long wrote: > >> You should be able to consider X-GM-THRID as immutable, that should have >> been called out in the documents. We never join threads. >> > > Thanks, this answers my question perfectly. > > > but the THREAD=3D concept >> seems fundamentally flawed to me that both the client and server require >> understanding of the threading algorithm. >> > > Could you elaborate a bit? Trojita does not have any builtin knowledge of > any threading algorithm, yet will happily issue and use > THREAD=3D{REFS,REFERENCES,**ORDEREDSUBJECT} and display the result to the > user. It works pretty well, actually. Best when combined with Dovecot due > to its THREAD=3DREFS support. > Why else would the threading model need to be so specified and have multiple choices? My assumption was because it allowed the client to know where a message it appended to the server (or maybe copied to another folder) would end up in the threading. Or even that it could just download the new messages in the folder and update the local thread information and know it was in-sync with the server. > Yes, this means that upon an arrival of a new message, it has to ask for > the threading info for a whole mailbox again simply because we might not > know the Message-Id of the existing threads, and therefore cannot replica= te > the server's algorithm. This is the "joy" of lazy loading in action :(. > I would think with THREAD=3DREFS, you can download the headers and lookup t= he possible matches using a SEARCH HEADER MESSAGE-ID construct to find the other messages. I've tried to address this waste of bandwidth by the INCTHREAD proposal > [1], but I didn't have time to push for its inclusion in FLOSS IMAP serve= rs > yet. > > What does "old thread with new arrivals are not listed as recent" mean? >> > > THREAD=3DREFERENCES and THREAD=3DORDEREDSUBJECT both sort the list of thr= eads > by the INTERNALDATE of the thread root. Trojita will always display the > threads in the order in which the THREAD response contained them. This > means that an old thread which receives a new response will still be list= ed > midway through the list of all threads, not at the end. Effectively, this > means that these algorithms are rather useless for a client which wants t= o > rely on server-side threading. > > Situation is much better with THREAD=3DREFS because the threads are sorte= d > by the most recent message in asubthread, not by the timestamp of the > thread root. When a new message arrives, the whole thread is brought to t= he > end of the THREAD response and the client knows that it shall be shown as= a > recent one. > > In Trojita, the ENVELOPE and INTERNALDATE are lazily loaded, fetched only > for currently visible messages (with some preload). We don't fetch these > for each message in a 100k mailbox for obvious reasons. However, this mea= ns > that we cannot reliably post-process the THREAD response by sorting the > threads according to the latest message in them. Ah, yes, we sort threads in our interface by the INTERNALDATE of the latest message in the thread. > New messages are clearly new, since they have newer UIDs (well, new to >> that folder at least). >> > > That's a good heuristic, thanks for suggesting that. It breaks when I > copy/move and old thread from my INBOX into some specific mailbox -- even > though the new mailbox probably contains newer messages, the old thread > would be displayed at the end, among the recent ones, due to the higher > UIDs. Still, I agree that it's better than having truly new messages sunk > deep withing the mailbox history. I'll have a look at implementing this f= or > algorithms other than THREAD=3DREFS. > > We always display messages in our "threads" in INTERNALDATE order. >> > > I agree that this is (or at least *should*) be the only useful sort order= . > I tend to agree with your marketing department in thinking that sorting b= y > e.g. the sender in order to find messages from a particular person is, > well, dumb. > > Do you handle the INTERNALDATE in conformance with the SHOULDs in RFC3501 > (i.e. they don't have to correlate with the order of UIDs, but truly > reflect the arrival of the message *to your server*, not to a *mailbox*)? > Do you also sort the "threads" themselves according to the INTERNALDATE o= f > the newest message in each thread? If so, could you make *this* feature > available over IMAP? I don't care for being able to sort by sender or > subject, but I do care for being able to reliably show truly recent > messages at the bottom (or top) of the view. > We just mapped INTERNALDATE to our "received time" for the message, so checking if that corresponds to the SHOULDs... yes, those should all be true. We have "implementation defined" exceptions when messages are migrated where we sometimes have to try and infer the original received time which may fall back to the Date: header in the worst case, but for all regular delivery, its the time of delivery. Yes, threads are sorted by the INTERNALDATE of the newest message in the thread. Our internal message-id (X-GM-MSGID) is based on the date received, and the original thread-id (which is exposed as X-GM-THRID) is the same as the message-id of the first message on the thread. We also have a concept of "latest thread-id" which is the message-id of the latest message on the thread, but we chose not to expose that since then the X-GM-THRID would not be immutable, since its updated whenever the thread gets a new message. And we may be moving away from that anyways and just using the original threadid with some other mechanism for forcing proper sort order on the thread, so it doesn't seem likely to get exposed via IMAP at this point. Brandon --089e0153728c39ad9804dc633227 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Fri, May 10, 2013 at 3:51 AM, Jan Kundr=E1t &l= t;jkt@flaska.net>= ; wrote:
On Thursday, 9 May 2013 23= :53:44 CEST, Brandon Long wrote:
You should be able to consider X-GM-THRID as immutable, that should have been called out in the documents. =A0We never join threads.

Thanks, this answers my question perfectly.


but the THREAD=3D concept
seems fundamentally flawed to me that both the client and server require understanding of the threading algorithm.

Could you elaborate a bit? Trojita does not have any builtin knowledge of a= ny threading algorithm, yet will happily issue and use THREAD=3D{REFS,REFER= ENCES,ORDEREDSUBJECT} and display the result to the user. It works p= retty well, actually. Best when combined with Dovecot due to its THREAD=3DR= EFS support.

Why else would the threading model n= eed to be so specified and have multiple choices? =A0My assumption was beca= use it allowed the client to know where a message it appended to the server= (or maybe copied to another folder) would end up in the threading. =A0Or e= ven that it could just download the new messages in the folder and update t= he local thread information and know it was in-sync with the server.
=A0
Yes, this means that upon an arrival of a new message, it has to ask for th= e threading info for a whole mailbox again simply because we might not know= the Message-Id of the existing threads, and therefore cannot replicate the= server's algorithm. This is the "joy" of lazy loading in act= ion :(.

I would think with THREAD=3DREFS, yo= u can download the headers and lookup the possible matches using a SEARCH H= EADER MESSAGE-ID construct to find the other messages.=A0
<= br>
I've tried to address this waste of bandwidth by the INCTHREAD proposal= [1], but I didn't have time to push for its inclusion in FLOSS IMAP se= rvers yet.

What does "old thread with new arrivals are not listed as recent"= mean?

THREAD=3DREFERENCES and THREAD=3DORDEREDSUBJECT both sort the list of threa= ds by the INTERNALDATE of the thread root. Trojita will always display the = threads in the order in which the THREAD response contained them. This mean= s that an old thread which receives a new response will still be listed mid= way through the list of all threads, not at the end. Effectively, this mean= s that these algorithms are rather useless for a client which wants to rely= on server-side threading.

Situation is much better with THREAD=3DREFS because the threads are sorted = by the most recent message in asubthread, not by the timestamp of the threa= d root. When a new message arrives, the whole thread is brought to the end = of the THREAD response and the client knows that it shall be shown as a rec= ent one.

In Trojita, the ENVELOPE and INTERNALDATE are lazily loaded, fetched only f= or currently visible messages (with some preload). We don't fetch these= for each message in a 100k mailbox for obvious reasons. However, this mean= s that we cannot reliably post-process the THREAD response by sorting the t= hreads according to the latest message in them.

Ah, yes, we sort threads in our interface by the = INTERNALDATE of the latest message in the thread.
=A0
New messages are clearly new, since they have newer UIDs (well, new to
that folder at least).

That's a good heuristic, thanks for suggesting that. It breaks when I c= opy/move and old thread from my INBOX into some specific mailbox -- even th= ough the new mailbox probably contains newer messages, the old thread would= be displayed at the end, among the recent ones, due to the higher UIDs. St= ill, I agree that it's better than having truly new messages sunk deep = withing the mailbox history. I'll have a look at implementing this for = algorithms other than THREAD=3DREFS.

We always display messages in our "threads" in INTERNALDATE order= .

I agree that this is (or at least *should*) be the only useful sort order. = I tend to agree with your marketing department in thinking that sorting by = e.g. the sender in order to find messages from a particular person is, well= , dumb.

Do you handle the INTERNALDATE in conformance with the SHOULDs in RFC3501 (= i.e. they don't have to correlate with the order of UIDs, but truly ref= lect the arrival of the message *to your server*, not to a *mailbox*)? Do y= ou also sort the "threads" themselves according to the INTERNALDA= TE of the newest message in each thread? If so, could you make *this* featu= re available over IMAP? I don't care for being able to sort by sender o= r subject, but I do care for being able to reliably show truly recent messa= ges at the bottom (or top) of the view.

We just mapped INTERNALDATE to our &= quot;received time" for the message, so checking if that corresponds t= o the SHOULDs... yes, those should all be true. =A0We have "implementa= tion defined" exceptions when messages are migrated where we sometimes= have to try and infer the original received time which may fall back to th= e Date: header in the worst case, but for all regular delivery, its the tim= e of delivery.

Yes, threads are sorted by the INTERNALDATE= of the newest message in the thread. =A0Our internal message-id (X-GM-MSGI= D) is based on the date received, and the original thread-id (which is expo= sed as X-GM-THRID) is the same as the message-id of the first message on th= e thread. =A0We also have a concept of "latest thread-id" which i= s the message-id of the latest message on the thread, but we chose not to e= xpose that since then the X-GM-THRID would not be immutable, since its upda= ted whenever the thread gets a new message. =A0And we may be moving away fr= om that anyways and just using the original threadid with some other mechan= ism for forcing proper sort order on the thread, so it doesn't seem lik= ely to get exposed via IMAP at this point.

Brandon
--089e0153728c39ad9804dc633227-- From cyrus@daboo.name Fri May 10 17:57:37 2013 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78D9321F8F2C for ; Fri, 10 May 2013 17:57:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.903 X-Spam-Level: X-Spam-Status: No, score=-100.903 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, MIME_QP_LONG_LINE=1.396, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZejWb+VfkZOn for ; Fri, 10 May 2013 17:57:32 -0700 (PDT) Received: from daboo.name (daboo.name [173.13.55.49]) by ietfa.amsl.com (Postfix) with ESMTP id 6A0BC21F8F20 for ; Fri, 10 May 2013 17:57:32 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by daboo.name (Postfix) with ESMTP id BF121431FCEE; Fri, 10 May 2013 20:57:26 -0400 (EDT) X-Virus-Scanned: amavisd-new at example.com Received: from daboo.name ([127.0.0.1]) by localhost (daboo.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o8IU85OVZdXg; Fri, 10 May 2013 20:57:26 -0400 (EDT) Received: from [17.45.162.251] (unknown [173.13.55.49]) by daboo.name (Postfix) with ESMTPSA id 6D12C431FCE0; Fri, 10 May 2013 20:57:25 -0400 (EDT) Date: Fri, 10 May 2013 20:57:25 -0400 From: Cyrus Daboo To: Brandon Long , =?UTF-8?Q?Jan_Kundr=C3=A1t?= Message-ID: <6447702B8EABAD897B88D551@cyrus.local> In-Reply-To: References: <05c6cf93-2e5e-469d-b356-0751f2bdd5df@flaska.net> X-Mailer: Mulberry/4.1.0a3 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline; size=833 Cc: imapext@ietf.org Subject: Re: [imapext] GMail's extensions: X-GM-THRID immutability X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 May 2013 00:57:37 -0000 Hi Brandon, --On May 10, 2013 1:41:49 PM -0700 Brandon Long wrote: > Why else would the threading model need to be so specified and have > multiple choices? =C2=A0My assumption was because it allowed the client = to > know where a message it appended to the server (or maybe copied to > another folder) would end up in the threading. =C2=A0Or even that it = could > just download the new messages in the folder and update the local thread > information and know it was in-sync with the server. Also disconnected clients - they may need to thread messages without=20 support from the server and ideally would want to use the same threading=20 algorithm as the server when displaying messages whilst offline. Indeed,=20 when I implemented THREAD in Mulberry I copied the REFERENCES algorithm for = use client-side. --=20 Cyrus Daboo From alexey.melnikov@isode.com Tue May 14 12:32:14 2013 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0D5521F8F53 for ; Tue, 14 May 2013 12:32:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.099 X-Spam-Level: X-Spam-Status: No, score=-102.099 tagged_above=-999 required=5 tests=[AWL=0.499, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sFA0IcFiuKLM for ; Tue, 14 May 2013 12:32:07 -0700 (PDT) Received: from waldorf.isode.com (cl-125.lon-03.gb.sixxs.net [IPv6:2a00:14f0:e000:7c::2]) by ietfa.amsl.com (Postfix) with ESMTP id 59BED21F8E9E for ; Tue, 14 May 2013 12:32:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1368559926; d=isode.com; s=selector; i=@isode.com; bh=7w9a8CTHV6SyvLJqfb/RsYSP8Sw7wcfsnvuzjTItKRk=; 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=UwoGnU6c0J55+/K3RV4thenylW3h4/g7ZVbsp0vSuXI6rMY26yOnmrslHswofRzN7Jiyv9 Hpv6E3VhnrrQJK3lHZ6q8G5L/79XQe1CjsFpmvdESgP3vpbLcrdxgdWrGpwxUF46wn4Kt/ vJuPixwTGTrXkZFUrZlU4JuXJi7wdzM=; Received: from [172.16.1.29] (shiny.isode.com [62.3.217.250]) by waldorf.isode.com (submission channel) via TCP with ESMTPA id ; Tue, 14 May 2013 20:32:05 +0100 Message-ID: <51929137.6030400@isode.com> Date: Tue, 14 May 2013 20:32:07 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 To: "imapext@ietf.org" References: <20130514192526.29433.43139.idtracker@ietfa.amsl.com> In-Reply-To: <20130514192526.29433.43139.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20130514192526.29433.43139.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------000700090707010408000805" Subject: [imapext] Fwd: I-D Action: draft-melnikov-rfc4551-bis-00.txt X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 May 2013 19:32:14 -0000 This is a multi-part message in MIME format. --------------000700090707010408000805 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit This is nearly identical to the RFC, but with references updated, errata 3401 and 3506 fixed. -------- Original Message -------- Subject: I-D Action: draft-melnikov-rfc4551-bis-00.txt Date: Tue, 14 May 2013 12:25:26 -0700 From: internet-drafts@ietf.org Reply-To: internet-drafts@ietf.org To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : IMAP Extension for Conditional STORE Operation or Quick Flag Changes Resynchronization Author(s) : Alexey Melnikov Filename : draft-melnikov-rfc4551-bis-00.txt Pages : 23 Date : 2013-05-14 Abstract: Often, multiple IMAP (RFC 3501) clients need to coordinate changes to a common IMAP mailbox. Examples include different clients working on behalf of the same user, and multiple users accessing shared mailboxes. These clients need a mechanism to synchronize state changes for messages within the mailbox. They must be able to guarantee that only one client can change message state (e.g., message flags) at any time. An example of such an application is use of an IMAP mailbox as a message queue with multiple dequeueing clients. The Conditional Store facility provides a protected update mechanism for message state information that can detect and resolve conflicts between multiple writing mail clients. The Conditional Store facility also allows a client to quickly resynchronize mailbox flag changes. This document defines an extension to IMAP (RFC 3501). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-melnikov-rfc4551-bis There's also a htmlized version available at: http://tools.ietf.org/html/draft-melnikov-rfc4551-bis-00 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ --------------000700090707010408000805 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit This is nearly identical to the RFC, but with references updated, errata 3401 and 3506 fixed.

-------- Original Message --------
Subject: I-D Action: draft-melnikov-rfc4551-bis-00.txt
Date: Tue, 14 May 2013 12:25:26 -0700
From: internet-drafts@ietf.org
Reply-To: internet-drafts@ietf.org
To: i-d-announce@ietf.org 


A New Internet-Draft is available from the on-line Internet-Drafts directories.


	Title           : IMAP Extension for Conditional STORE Operation or Quick Flag Changes Resynchronization
	Author(s)       : Alexey Melnikov
	Filename        : draft-melnikov-rfc4551-bis-00.txt
	Pages           : 23
	Date            : 2013-05-14

Abstract:
   Often, multiple IMAP (RFC 3501) clients need to coordinate changes to
   a common IMAP mailbox.  Examples include different clients working on
   behalf of the same user, and multiple users accessing shared
   mailboxes.  These clients need a mechanism to synchronize state
   changes for messages within the mailbox.  They must be able to
   guarantee that only one client can change message state (e.g.,
   message flags) at any time.  An example of such an application is use
   of an IMAP mailbox as a message queue with multiple dequeueing
   clients.

   The Conditional Store facility provides a protected update mechanism
   for message state information that can detect and resolve conflicts
   between multiple writing mail clients.

   The Conditional Store facility also allows a client to quickly
   resynchronize mailbox flag changes.

   This document defines an extension to IMAP (RFC 3501).


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-melnikov-rfc4551-bis

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-melnikov-rfc4551-bis-00


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

--------------000700090707010408000805-- From jkt@flaska.net Wed May 15 08:53:36 2013 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7AC0B21F880F for ; Wed, 15 May 2013 08:53:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.7 X-Spam-Level: X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_64=0.6, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cfmHfxDdHMSN for ; Wed, 15 May 2013 08:53:35 -0700 (PDT) Received: from latimerie.flaska.net (latimerie.flaska.net [IPv6:2a02:2b88:2:1::4a7:333]) by ietfa.amsl.com (Postfix) with ESMTP id 9B4BD11E80C5 for ; Wed, 15 May 2013 08:52:56 -0700 (PDT) Received: by latimerie.flaska.net (Postfix, from userid 1000) id EB9F660A1A; Wed, 15 May 2013 17:52:50 +0200 (CEST) From: =?iso-8859-1?Q?Jan_Kundr=E1t?= To: Date: Wed, 15 May 2013 17:52:46 +0200 User-Agent: trojita/v0.3.93-22-g3352b8c; Qt/4.8.4; X11; Linux; MIME-Version: 1.0 Message-ID: <388f4d19-6eba-4b4b-9b6d-f1d3feb71d7e@flaska.net> In-Reply-To: References: <05c6cf93-2e5e-469d-b356-0751f2bdd5df@flaska.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Subject: [imapext] Re: GMail's extensions: X-GM-THRID immutability X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 May 2013 15:53:36 -0000 On Friday, 10 May 2013 22:41:49 CEST, Brandon Long wrote:=0A> Why else = would the threading model need to be so specified and have=0A> multiple= choices? My assumption was because it allowed the client to know=0A> = where a message it appended to the server (or maybe copied to another=0A= > folder) would end up in the threading. Or even that it could just do= wnload=0A> the new messages in the folder and update the local thread i= nformation and=0A> know it was in-sync with the server.=0A=0AI agree th= at it is good to have the threading algorithm well-specified. However, = for me, the only bonus of the server-side threading is that it allows f= or threading of messages which have not been downloaded yet. The idea i= s that transferring a list of threading is cheaper than fetching the re= quired headers for all messages.=0A=0A> I would think with THREAD=3DREF= S, you can download the headers and lookup the=0A> possible matches usi= ng a SEARCH HEADER MESSAGE-ID construct to find the=0A> other messages.= =0A=0ATrue, but this leads to the O(n) latency (the pathologic case are= deep ancient threads with the "References" header all containing just = a single message). That's a lot of round trips.=0A=0A> Ah, yes, we sort= threads in our interface by the INTERNALDATE of the latest=0A> message= in the thread.=0A[...]=0A> And we may be moving away from that anyways= and just=0A> using the original threadid with some other mechanism for= forcing proper=0A> sort order on the thread, so it doesn't seem likely= to get exposed via IMAP=0A> at this point.=0A=0AFrom what you said, it= looks like your server supports sorting by INTERNALDATE. I understand = that mapping this into some message attribute would not be terribly use= ful, no matter whether per-thread or per-message -- if it's a message a= ttribute, one could just as well fetch the INTERNALDATE and be done wit= h it.=0A=0AHowever, suppose there was a hypothetical SORT=3DINTERNALDAT= E capability which would work exactly like the existing SORT extension,= but only allowing/requiring to sort via INTERNALDATE. The result would= be returned as the plain old SORT response (or, better, via ESEARCH fo= r easier pipelining). Would you be willing to add this to GMail?=0A=0AI= 'll be happy to prepare a draft for this extension and to implement it = in Trojita. Are the other implementors, both server- and client-side, i= nterested?=0A=0AWith kind regards,=0AJan=0A=0A-- =0ATrojit=C3=A1, a fas= t Qt IMAP e-mail client -- http://trojita.flaska.net/ From dkarp@zimbra.com Wed May 15 09:08:37 2013 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0E2D21F901D for ; Wed, 15 May 2013 09:08:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8wSrgQTAON5V for ; Wed, 15 May 2013 09:08:31 -0700 (PDT) Received: from edge01-zcs.vmware.com (edge01-zcs.vmware.com [208.91.2.22]) by ietfa.amsl.com (Postfix) with ESMTP id 04A7221F85D6 for ; Wed, 15 May 2013 09:08:30 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by edge01-zcs.vmware.com (Postfix) with ESMTP id 4F8A85BCB; Wed, 15 May 2013 09:08:30 -0700 (PDT) Received: from edge01-zcs.vmware.com ([127.0.0.1]) by localhost (edge01-zcs.vmware.com [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id acg2SqxHDkKN; Wed, 15 May 2013 09:08:20 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by edge01-zcs.vmware.com (Postfix) with ESMTP id 475985D5B; Wed, 15 May 2013 09:08:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at edge01-zcs.vmware.com Received: from edge01-zcs.vmware.com ([127.0.0.1]) by localhost (edge01-zcs.vmware.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id Ef02-4W-JDU9; Wed, 15 May 2013 09:08:20 -0700 (PDT) Received: from mbs01-zcs.vmware.com (mbs01-zcs.vmware.com [10.113.162.14]) by edge01-zcs.vmware.com (Postfix) with ESMTP id 062245BCB; Wed, 15 May 2013 09:08:20 -0700 (PDT) Date: Wed, 15 May 2013 09:08:19 -0700 (PDT) From: Dan Karp To: Jan =?utf-8?Q?Kundr=C3=A1t?= Message-ID: <1222915689.199545.1368634099653.JavaMail.zimbra@zimbra.com> In-Reply-To: <388f4d19-6eba-4b4b-9b6d-f1d3feb71d7e@flaska.net> References: <05c6cf93-2e5e-469d-b356-0751f2bdd5df@flaska.net> <388f4d19-6eba-4b4b-9b6d-f1d3feb71d7e@flaska.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Mailer: Zimbra 8.0.4_GA_5726 (ZimbraWebClient - GC26 (Mac)/8.0.4_GA_5726) Thread-Topic: GMail's extensions: X-GM-THRID immutability Thread-Index: 4sZ0sSgIMWf1vI6IGy+ifVTvgMq0iA== Cc: imapext@ietf.org Subject: Re: [imapext] GMail's extensions: X-GM-THRID immutability X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 May 2013 16:08:37 -0000 > However, suppose there was a hypothetical SORT=INTERNALDATE capability which > would work exactly like the existing SORT extension, but only > allowing/requiring to sort via INTERNALDATE. The result would be returned as > the plain old SORT response (or, better, via ESEARCH for easier pipelining). (Just a note: Any server that advertises a capability starting with "SORT" must also implement the entire SORT extension. So you'd need to call it something else.) A server that supports the base-level SORT extension indicates this with a capability name which starts with "SORT". Future, upwards- compatible extensions to the SORT extension will all start with "SORT", indicating support for this base level. - Dan From lear@cisco.com Wed May 15 21:47:33 2013 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F7E421F8605 for ; Wed, 15 May 2013 21:47:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.493 X-Spam-Level: X-Spam-Status: No, score=-110.493 tagged_above=-999 required=5 tests=[AWL=0.107, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G2XPLtb4DEeR for ; Wed, 15 May 2013 21:47:28 -0700 (PDT) Received: from ams-iport-3.cisco.com (ams-iport-3.cisco.com [144.254.224.146]) by ietfa.amsl.com (Postfix) with ESMTP id 698DA21F86CA for ; Wed, 15 May 2013 21:47:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9798; q=dns/txt; s=iport; t=1368679647; x=1369889247; h=message-id:date:from:mime-version:to:subject:references: in-reply-to; bh=Yd+N5C9Y87uKov4ZW305UCE2P8+bdbqXB6qRaqOWJn4=; b=N8KpE1qY3einT6fgG4PrQm4bEQmY8EVmKQony/vqBUytsoOgScHcy5Gb aKs54YRSBpqtu5EaJ35gTyUVFAuQRS5Bz4PNQ9BjqJOefA0xMPDfF4XK7 PVgN0YjGeNtYt8t6GDJRQsHUj+q63w4HhmNZB3IYkt9xXFkYch3bb4ayM E=; X-Files: : None X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmsHAGtklFGQ/khM/2dsb2JhbABbgweDc4Vet2OBAhZ0gh8BAQEEHQZFISIKIQICDwIsEAIIBg0GAgEBEId4qzGKDYdLjVwQgTmCQoETA496hzqRPoFYgTo6gTU X-IronPort-AV: E=Sophos;i="4.87,681,1363132800"; d="eml'208?scan'208,208";a="13496898" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-3.cisco.com with ESMTP; 16 May 2013 04:47:24 +0000 Received: from mctiny.local ([10.61.169.178]) by ams-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r4G4lMO6018432 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 16 May 2013 04:47:22 GMT Message-ID: <519464D9.70408@cisco.com> Date: Thu, 16 May 2013 06:47:21 +0200 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: qresync WG References: In-Reply-To: X-Enigmail-Version: 1.5.1 X-Forwarded-Message-Id: Content-Type: multipart/mixed; boundary="------------080901010003040506010201" Subject: [imapext] Fwd: Corrected References, More Exhortation - NomCom 2013-2014 Call for Volunteers V1.2 X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 May 2013 04:47:33 -0000 This is a multi-part message in MIME format. --------------080901010003040506010201 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Please consider volunteering for NOMCOM. Leadership in the IETF is chosen by NOMCOM, and this is your chance to participate in that selection. Eliot --------------080901010003040506010201 Content-Type: message/rfc822; name="Corrected References, More Exhortation - NomCom 2013-2014 Call for Volunteers V1_2.eml" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename*0="Corrected References, More Exhortation - NomCom 2013-2014 Ca"; filename*1="ll for Volunteers V1_2.eml" X-Mozilla-Keys: Received: from rcdn-iport-6.cisco.com (173.37.86.77) by mail.cisco.com (173.36.12.83) with Microsoft SMTP Server (TLS) id 14.2.318.4; Tue, 14 May 2013 13:12:54 -0500 Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-6.cisco.com with ESMTP; 14 May 2013 18:12:49 +0000 Received: from rcdn-inbound-h.cisco.com (rcdn-inbound-h.cisco.com [72.163.7.177]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id r4EICm3q026240; Tue, 14 May 2013 18:12:48 GMT Authentication-Results: rcdn-inbound-h.cisco.com; dkim=pass (signature verified [TEST]) header.i=@ietf.org X-from-outside-Cisco: 12.22.58.30 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AnMCAD1+klEMFjoenGdsb2JhbABagmbBA4EBFg4BAQEBAQYNCQkUIQeCHwEBAQEDAQEBDAECCx0GAQEEChgSAgMBAgYCAQEfHwgIAwEuHQoEEwUPDodqAQKfNQGBC4p7AQGDMoEMAQWGY4cdEQaNXBCBO4JyYapLgTiBcjU X-IronPort-AV: E=Sophos;i="4.87,671,1363132800"; d="scan'208";a="105540139" Received: from mail.ietf.org ([12.22.58.30]) by rcdn-inbound-h.cisco.com with ESMTP; 14 May 2013 18:12:46 +0000 Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CC96511E8100; Tue, 14 May 2013 11:12:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1368555140; bh=rcBAPkHa1Elduj+oF2MJJXg/gh+SDhUUqkBO1VtC4HM=; h=From:To:Subject:Date:Message-ID:Content-Type:Content-ID: Content-Transfer-Encoding:MIME-Version:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:Sender; b=SS4sW9yz0KDoqNHyNqJFU3MOBqRLHCQsCsnJFSbelwc27ePtlXaVAFQWfEj5h/Yv/ Ll5EOfQhmM5Ync5JQbvLwNyxlUYf4/o/SkX6FdBsE/iYgD8V0LXgTp3IGicgZfkS0h mT83mqdkIlcLxSrY02DoGmVf06sJZ77qy87YvHhk= X-Original-To: ietf-announce@ietfa.amsl.com Delivered-To: ietf-announce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DAFBB11E80FF for ; Tue, 14 May 2013 11:11:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KQVgSNNKfgi6 for ; Tue, 14 May 2013 11:11:35 -0700 (PDT) Received: from exprod6og127.obsmtp.com (exprod6og127.obsmtp.com [64.18.1.78]) by ietfa.amsl.com (Postfix) with ESMTP id 858CD11E8100 for ; Tue, 14 May 2013 11:11:33 -0700 (PDT) Received: from osprey.verisign.com ([216.168.239.75]) (using TLSv1) by exprod6ob127.postini.com ([64.18.5.12]) with SMTP ID DSNKUZJ+VSXfmMYJ2H9h9FZShUJb7stNgLh1@postini.com; Tue, 14 May 2013 11:11:33 PDT Received: from brn1wnexcas01.vcorp.ad.vrsn.com (brn1wnexcas01.vcorp.ad.vrsn.com [10.173.152.205]) by osprey.verisign.com (8.13.6/8.13.4) with ESMTP id r4EIBTR3027642 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 14 May 2013 14:11:32 -0400 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.02.0342.003; Tue, 14 May 2013 14:11:29 -0400 From: "Mankin, Allison" To: "ietf-announce@ietf.org" Subject: Corrected References, More Exhortation - NomCom 2013-2014 Call for Volunteers V1.2 Thread-Topic: Corrected References, More Exhortation - NomCom 2013-2014 Call for Volunteers V1.2 Thread-Index: AQHOUM503u+luJnsm0yUnq5CHQ4JFw== Date: Tue, 14 May 2013 18:11:28 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.173.152.4] Content-Type: text/plain; charset="us-ascii" Content-ID: <24C255D6FD8FDB4388BF564E5D24B318@verisign.com> Content-Transfer-Encoding: quoted-printable X-BeenThere: ietf-announce@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IETF announcement list. No discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: Errors-To: ietf-announce-bounces@ietf.org Return-Path: ietf-announce-bounces@ietf.org X-MS-Exchange-Organization-AuthSource: xhc-aln-x09.cisco.com X-MS-Exchange-Organization-AuthAs: Internal X-MS-Exchange-Organization-AuthMechanism: 10 MIME-Version: 1.0 The IETF nominating committee (nomcom) process for 2013-14 is under way. Th= e=20 IETF nomcom appoints folks to fill the open slots on the IAOC, the IAB, and the IESG. Ten voting members for the nomcom are selected in a verifiabl= y random way from a pool of volunteers. The more volunteers, the better chanc= e we have of choosing a random yet representative cross section of the IETF population. This year, a challenge: let's get beyond the 100-mark for number of volunteers. Let's get to 200 volunteers!=20 More exhortation: please volunteer at greater rates - we won't get to 200 a= s=20 we're going now! Also, please follow the instruction about Subject line (b= elow). Corrected references: The details of the operation of the nomcom can be fou= nd=20 in RFCs 3777, 5078, 5633, 5680, and 6859. Four of those RFCs (3777, 5633,= =20 5680 and 6859) comprise BCP 10. We will also reference RFC 3797. =20 Volunteers must have attended 3 of the past 5 IETF meetings. As specified = in RFC 3777, that means three out of the five past meetings up to the time thi= s email announcement goes out to start the solicitation of volunteers. The fi= ve meetings out of which you must have attended three are IETF 82, 83, 84, 85,= 86. If you qualify, please volunteer. However, much as we want this, before yo= u=20 decide to volunteer, please be sure you are willing to forgo appointment to any of the positions for which this nomcom is responsible. =20 =20 The list of people and posts whose terms end with the March 2014 IETF meeting, and thus the positions for which this nomcom is responsible, are IAOC: Chris Griffiths IAB: Bernard Aboba Marc Blanchet Ross Callon Eliot Lear Hannes Tschofenig IESG: Barry Leiba (Applications) Brian Haberman (Internet) Benoit Claise (Operations and Management) Gonzalo Camarillo (RAI) Stewart Bryant (Routing) Sean Turner (Security) Martin Stiemerling (Transport) The primary activity for this nomcom will begin in July 2013 and should be completed in January 2014. The nomcom will have regularly scheduled conference calls to ensure progress. There will be activities to collect=20 requirements from the community, review candidate questionnaires, review feedback from community members about candidates, and talk to=20 candidates. Thus, being a nomcom member does require some time commitment. Please volunteer by sending me an email before 11:59 pm EDT (UTC -4 hours)= =20 June 16, 2013, as follows: To: amankin@verisign.com Subject: Nomcom 2013-14 Volunteer Please include the following information in the email body: =20 // First/Given Name followed by Last/Family Name // matching how you enter it in the IETF Registration Form) // Typically what goes in the Company field // in the IETF Registration Form [] =20 =20 // For confirmation if selected You should expect an email response from me within 3 business days stating whether or not you are qualified. If you don't receive this response, please re-send your email with the tag "RESEND"" added to the subject line. If you are not yet sure if you would like to volunteer, please consider that nomcom members play a very important role in shaping the leadership of the IETF. Volunteering for the nomcom is a great way to contribute to the IETF!=20 I will be publishing a more detailed target timetable, as well as details=20 of the randomness seeds to be used for the RFC 3797 selection process,=20 within the next couple weeks. =20 Thank you! Allison Mankin amankin@verisign.com P.S. Because the 2012-2013 nomcom is still at work, we cannot use the ietf addresses for the nomcom chair or the nomcom committee yet, so please send all the volunteer mail (and any questions/comments you may have) to the=20 address given.=20 --------------080901010003040506010201-- From dave@cridland.net Mon May 20 11:20:32 2013 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44BFB21F8E41 for ; Mon, 20 May 2013 11:20:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qdcd7MgfFIdS for ; Mon, 20 May 2013 11:20:28 -0700 (PDT) Received: from mail-oa0-f46.google.com (mail-oa0-f46.google.com [209.85.219.46]) by ietfa.amsl.com (Postfix) with ESMTP id E7D0721F8DA6 for ; Mon, 20 May 2013 11:20:26 -0700 (PDT) Received: by mail-oa0-f46.google.com with SMTP id h2so8042847oag.5 for ; Mon, 20 May 2013 11:20:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cridland.net; s=google; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=ZO173YHmIL12OC3Fu7TaK1hD/wU2EZLLgBd0Sl1SnS4=; b=hmXuqOA5lXx1S0DPv+oNJ4iRoKq5GqkRNbdGWIXXBfg3JCJKYr7xwJrRtoxoV4pXa1 LeVU0TRqqwT/5bCvkqc/KCLNLjtgy/VL4LSdORa/bc7VU/4Wd8U2QtzCRdB2hDPjWIqH keGhHcZmRQQOragpDqLe7BAYeT6/xg8oiSqw0= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type:x-gm-message-state; bh=ZO173YHmIL12OC3Fu7TaK1hD/wU2EZLLgBd0Sl1SnS4=; b=ecDgYJDkKRLOs6WwudSWC6tlqvbjmOOEspv7FYserRWY/ardm7S3s3cmoakWSsJAKf S8+OpKMjixg1MhQ5PZ0ggX3NudDW3TmiQGl9lg2sISysdVdb/NY6GU6ka9kKaIV+5SsM hYHYh+O+Y9MDjdKIgaj8I/ADd1OiCHK+YI7H121G7PP/QSj9WYvD/62QTzHZBrT7YXjR rV+nRF3bcYc6iTVrDqX3vKj+Fr6tt7ZDW7rsMaRRtPL6ZdqMWjfbEpytQU7XlR0zxFZP kaAyXH3hIt5c3w/tJbu/EKfRsf9YFPqKjFizexC4CqOYLnuJcgXPcCHWfUPJJzuTj5SG EBJA== MIME-Version: 1.0 X-Received: by 10.182.135.161 with SMTP id pt1mr5545788obb.3.1369074026332; Mon, 20 May 2013 11:20:26 -0700 (PDT) Received: by 10.60.62.146 with HTTP; Mon, 20 May 2013 11:20:26 -0700 (PDT) Date: Mon, 20 May 2013 19:20:26 +0100 Message-ID: From: Dave Cridland To: "imapext@ietf.org" Content-Type: multipart/alternative; boundary=089e013c6c3e02d87804dd2a635a X-Gm-Message-State: ALoCoQkyvFE8eVU+AzMnwu0tzrVbteieOkXwFJPdiI/wkwmLi+PdUXbOM5HxLYWcER2a9ABR/aVY Subject: [imapext] qresync WG adoption call X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 May 2013 18:20:32 -0000 --089e013c6c3e02d87804dd2a635a Content-Type: text/plain; charset=ISO-8859-1 Folks, We now have two drafts by Alexey published: - draft-melnikov-rfc4551-bis-00 (CONDSTORE) - draft-melnikov-5162bis-00 (QRESYNC) I'd like to propose that the working group adopt these as our start point. Therefore this constitutes a call for adoption of both documents; reviews would be very useful at this stage and I'll prod people if there's no volunteers. Thanks, Dave. (As qresync co-chairman) --089e013c6c3e02d87804dd2a635a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Folks,

We now have two drafts by Alexey= published:

=A0- draft-melnikov-rfc4551-bis-= 00 (CONDSTORE)
=A0- draft-melnikov-5162bis-00 (QRESYNC)

I'd like to propose that the working group adopt t= hese as our start point.

Therefore thi= s constitutes a call for adoption of both documents; reviews would be very = useful at this stage and I'll prod people if there's no volunteers.=

Thanks,

Dave. (As qresync co-chairman)
--089e013c6c3e02d87804dd2a635a-- From slusarz@horde.org Mon May 20 12:53:42 2013 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CC8E21F96DE for ; Mon, 20 May 2013 12:53:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.422 X-Spam-Level: * X-Spam-Status: No, score=1.422 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mFkDIG2ob8dn for ; Mon, 20 May 2013 12:53:36 -0700 (PDT) Received: from qmta04.emeryville.ca.mail.comcast.net (qmta04.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:43:76:96:30:40]) by ietfa.amsl.com (Postfix) with ESMTP id 5202321F96D5 for ; Mon, 20 May 2013 12:53:36 -0700 (PDT) Received: from omta04.emeryville.ca.mail.comcast.net ([76.96.30.35]) by qmta04.emeryville.ca.mail.comcast.net with comcast id eKWE1l0030lTkoCA4KtcPC; Mon, 20 May 2013 19:53:36 +0000 Received: from bigworm.curecanti.org ([71.229.167.0]) by omta04.emeryville.ca.mail.comcast.net with comcast id eKta1l00d00qwSn8QKtbkj; Mon, 20 May 2013 19:53:35 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) (Authenticated sender: slusarz) by bigworm.curecanti.org (Postfix) with ESMTPSA id 9770468068 for ; Mon, 20 May 2013 13:53:03 -0600 (MDT) Received: from schrute.curecanti.org (schrute.curecanti.org [172.18.5.4]) by bigworm.curecanti.org (Horde Framework) with HTTP; Mon, 20 May 2013 13:53:03 -0600 Date: Mon, 20 May 2013 13:53:03 -0600 Message-ID: <20130520135303.Horde.npUBqY2PMh-9C3OAQje4LA1@bigworm.curecanti.org> From: Michael M Slusarz To: imapext@ietf.org References: In-Reply-To: User-Agent: Internet Messaging Program (IMP) H5 (6.1.0-git) Accept-Language: en X-Originating-IP: 172.18.5.4 X-Remote-Browser: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:21.0) Gecko/20100101 Firefox/21.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=1369079616; bh=TQdyarb83M5JcdK6i0SIxmEmS8/tG+6q4gxjBwl/4es=; h=Received:Received:Received:Received:Date:Message-ID:From:To: Subject:Content-Type:MIME-Version; b=TK43MoX3rzR48kBDHpaGFC3trj+gR0l6QJvtddiIVIPqzCjbkrz5PesTazL1vJC2q 3Zf83LSr/x3NFb5kHPTq8Jkw6d1Xl4VwHW41tOiCo6Bq1yGyq5mVYI47S+vXVbRWR9 o8KkQCswxvjTwq8xiLb6l5ih648NbgGO0ZO2/sp4OA7UycSveYiU+SsFlA42Yuuo63 XBFIex7HyGt/MlwI9c5/6sm3YDjGBdx+Yf/wMmTYSZIgswbJhrG+AQ0HoGdcw59tqG YE4PvauEGREZbsFxZnuDDy1OPhtfck1inwiHLCcV62mZpBV06a8UOEwCTePxa2uSqV OyyA9jQo6Yemg== Subject: Re: [imapext] qresync WG adoption call X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 May 2013 19:53:42 -0000 Quoting Dave Cridland : > Folks, > > We now have two drafts by Alexey published: > > - draft-melnikov-rfc4551-bis-00 (CONDSTORE) > - draft-melnikov-5162bis-00 (QRESYNC) > > I'd like to propose that the working group adopt these as our start point. Does this mean the current inclination is to issue updates of the current documents rather than trying to combine into a single "IMAP synchronization extensions" doc? I personally feel the latter makes more sense from a protocol implementor's standpoint, especially since the subtleties and interplay between the two extensions could more easily be explained. Although I understand this requires drafting of an entirely new document rather than incremental tweaking of existing text. michael ___________________________________ Michael Slusarz [slusarz@horde.org] From dave@cridland.net Mon May 20 13:20:13 2013 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9754021F90DF for ; Mon, 20 May 2013 13:20:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 53-NNRoKiUcS for ; Mon, 20 May 2013 13:20:09 -0700 (PDT) Received: from mail-oa0-f52.google.com (mail-oa0-f52.google.com [209.85.219.52]) by ietfa.amsl.com (Postfix) with ESMTP id 520B821F90BB for ; Mon, 20 May 2013 13:20:09 -0700 (PDT) Received: by mail-oa0-f52.google.com with SMTP id h1so8049826oag.39 for ; Mon, 20 May 2013 13:20:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cridland.net; s=google; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=leikgJTOFOjrzLuYxL3ZVTMLrZJPMFuu6zSASSolpqA=; b=WW00A3LvXpSYjJh8YxP00vl+gsE33o7q41Ht4OY69xj6us8jXM6HQIKQLcxf+jo4p0 Lxw7rudr0tu/CQmx+va9vrdTFVtGNPRd3tiu0EtY75vgXA4z27MubSMgxV6eSdUZTgx2 Pxs/zW+5i+VyTRVrwCDLshHAF8Y+VQw+V6nKA= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=leikgJTOFOjrzLuYxL3ZVTMLrZJPMFuu6zSASSolpqA=; b=ivVWGct0h+z8xymBbxdIDIt8LC2jwHUwpIx6YTxDSs9bI8WjMLlsCU3KpcfufcsW30 WaQrFNCGAMX2Ts8BTWugyrNaIPi80w/EXJlsUO6/TuL6S+i847LbCHKI38MiVp7XzvAt yL4zmmpAhdtNDFaFxHX/Ks5ACGOLVXni5GGTE9xbUZJFrmKwxCSOQLp9LU68mYi6byZi ROPOKaWdq2LULuAJfN0IE5K7CpYTelX9TbP+tJUxL7Uf2R5b5T4vh1nkpQgC9wB5S/VQ i+OvVJtsiHEHpv5PWRyOjLM0FrCAhEuKhpe21143o2qryWgDrCtPI849SPIvJ5bg/PpA yVKw== MIME-Version: 1.0 X-Received: by 10.60.134.204 with SMTP id pm12mr12397549oeb.67.1369081208738; Mon, 20 May 2013 13:20:08 -0700 (PDT) Received: by 10.60.62.146 with HTTP; Mon, 20 May 2013 13:20:08 -0700 (PDT) In-Reply-To: <20130520135303.Horde.npUBqY2PMh-9C3OAQje4LA1@bigworm.curecanti.org> References: <20130520135303.Horde.npUBqY2PMh-9C3OAQje4LA1@bigworm.curecanti.org> Date: Mon, 20 May 2013 21:20:08 +0100 Message-ID: From: Dave Cridland To: Michael M Slusarz Content-Type: multipart/alternative; boundary=047d7b471dc41ddf3004dd2c0f3b X-Gm-Message-State: ALoCoQlSkuKX4NfV7ee1FE5+z4IxJqU6hSWTT91hfkCuhfG88uG5VQz1iqxIWyc8oM37Ye8r1HsC Cc: "imapext@ietf.org" Subject: Re: [imapext] qresync WG adoption call X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 May 2013 20:20:13 -0000 --047d7b471dc41ddf3004dd2c0f3b Content-Type: text/plain; charset=ISO-8859-1 As co-chairman: On Mon, May 20, 2013 at 8:53 PM, Michael M Slusarz wrote: > Does this mean the current inclination is to issue updates of the current > documents rather than trying to combine into a single "IMAP synchronization > extensions" doc? > > It means this is the current proposal on the table, not that a single document is ruled out. Either is explicitly allowed by our charter. Adopting these as working group drafts would not preclude either, as far as I'm concerned - once they're the working group's, we can do whatever we have consensus on. > I personally feel the latter makes more sense from a protocol > implementor's standpoint, especially since the subtleties and interplay > between the two extensions could more easily be explained. Although I > understand this requires drafting of an entirely new document rather than > incremental tweaking of existing text. > There's pros and cons each way; if anyone feels strongly (or would like to explore the pros and cons) feel free to speak up. Dave. --047d7b471dc41ddf3004dd2c0f3b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
As co-chairman:

On Mon, May 20, 2013 at 8:53 PM, Michael M Slusarz <slu= sarz@horde.org> wrote:
Does this mean the current inclination is to issue updates of the= current documents rather than trying to combine into a single "IMAP s= ynchronization extensions" doc?


It means this is the current pro= posal on the table, not that a single document is ruled out. Either is expl= icitly allowed by our charter. Adopting these as working group drafts would= not preclude either, as far as I'm concerned - once they're the wo= rking group's, we can do whatever we have consensus on.
=A0
I personally feel the latter makes more sense from a protocol implementor&#= 39;s standpoint, especially since the subtleties and interplay between the = two extensions could more easily be explained. =A0Although I understand thi= s requires drafting of an entirely new document rather than incremental twe= aking of existing text.

There's pros and cons each way; = if anyone feels strongly (or would like to explore the pros and cons) feel = free to speak up.

Dave.
--047d7b471dc41ddf3004dd2c0f3b-- From alexey.melnikov@isode.com Thu May 23 03:08:59 2013 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D019621F96F2 for ; Thu, 23 May 2013 03:08:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.349 X-Spam-Level: X-Spam-Status: No, score=-102.349 tagged_above=-999 required=5 tests=[AWL=0.250, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dmvgm+6CHmcF for ; Thu, 23 May 2013 03:08:54 -0700 (PDT) Received: from statler.isode.com (statler.isode.com [62.3.217.254]) by ietfa.amsl.com (Postfix) with ESMTP id F3F5C21F96F4 for ; Thu, 23 May 2013 03:08:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1369303728; d=isode.com; s=selector; i=@isode.com; bh=V33AznPB5hLnlg8tzr/lwwP1Ee5taMQDYri0Fm7mHL8=; 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=uxVY/ZkLuwXVLISbGJFOW8+xKQw1Od7Aw6G38bfm/olmdGI27R+7OrgJ1EO3VHjvQWGNSW xq0sOx/+6R1Ia2YVjRXaTYVExcXN6e/ZzSowBS8pChynVy9KgVeCAYJQ8ZDYYrkyh+yAMj 7GJGY/rT9S/ihrGc/1671vpbfxLMKmY=; Received: from [172.16.1.29] (shiny.isode.com [62.3.217.250]) by statler.isode.com (submission channel) via TCP with ESMTPA id ; Thu, 23 May 2013 11:08:48 +0100 Message-ID: <519DDAFB.7060207@isode.com> Date: Thu, 23 May 2013 10:01:47 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 To: Michael M Slusarz References: <20130520135303.Horde.npUBqY2PMh-9C3OAQje4LA1@bigworm.curecanti.org> In-Reply-To: <20130520135303.Horde.npUBqY2PMh-9C3OAQje4LA1@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] qresync WG adoption call X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 May 2013 10:08:59 -0000 On 20/05/2013 20:53, Michael M Slusarz wrote: > Quoting Dave Cridland : > >> Folks, >> >> We now have two drafts by Alexey published: >> >> - draft-melnikov-rfc4551-bis-00 (CONDSTORE) >> - draft-melnikov-5162bis-00 (QRESYNC) >> >> I'd like to propose that the working group adopt these as our start >> point. > > Does this mean the current inclination is to issue updates of the > current documents rather than trying to combine into a single "IMAP > synchronization extensions" doc? > > I personally feel the latter makes more sense from a protocol > implementor's standpoint, especially since the subtleties and > interplay between the two extensions could more easily be explained. > Although I understand this requires drafting of an entirely new > document rather than incremental tweaking of existing text. As Dave said, our WG Charter doesn't restrict us in what we can do here. If people want a single document, my preferred way of doing that would be: 1) first post 2 separate drafts updating CONDSTORE and QRESYNC first (so that people can use wdiff to see what changed) 2) then produce a combined document with CONDSTORE inserted into QRESYNC (again, so that people can diff relevant parts) 3) start rearranging & rewriting text to make sure that CONDSTORE and QRESYNC bits are consistent with each other. This is going to be more work, but I am happy to try if people see benefits. From dave@cridland.net Thu May 23 03:27:45 2013 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83E9721F96AB for ; Thu, 23 May 2013 03:27:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7oTjGDE4CPCz for ; Thu, 23 May 2013 03:27:41 -0700 (PDT) Received: from mail-oa0-f50.google.com (mail-oa0-f50.google.com [209.85.219.50]) by ietfa.amsl.com (Postfix) with ESMTP id 4471B21F9633 for ; Thu, 23 May 2013 03:27:41 -0700 (PDT) Received: by mail-oa0-f50.google.com with SMTP id l20so4175750oag.9 for ; Thu, 23 May 2013 03:27:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cridland.net; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=ByTgpkTQnf5IpNlHIkc3oQz28khaBL5Rh+vssh1PADU=; b=HNiJrLSlIQ1KIMa6aTmn9TXXlrlYIO6UL064/KjE6sGGLqt4I1MS/8lAUBKnxa9Tft giHz1jxWcGvsYHykm+HYgiaX0AbrtZqWx9MblsSR7RcZhxuUk6uyqFHxu12eOzSdxfLD n9pFJmH0HBZ3gHfnRLcoZe9rbvYE5OOqY8n4c= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:x-gm-message-state; bh=ByTgpkTQnf5IpNlHIkc3oQz28khaBL5Rh+vssh1PADU=; b=VvPTCDfOCEe71tmANSP+YRLXXSSFSgeoiG1qv1i0XFR1F1BKsWIseOcPE4njj33iIA ySxbRZrJ2zJdINxM7+bh7gKNb7IKQJnJ9UFm40KdkkIerywbOtkcM4afsLF6wwxEk0Bo HTsdqRQCHsRd41g95dpFlXygjj+iXMvJFIlP1LrJCEfB1yT+4ZWAMXcj3vRmLsmMnDmm Z7ntUnhFCBU7EjWLX023jEhWeTUkYsw9qfHZweAWpGD+0FKuaoWOu5c23pco7C3lRrga 4ly4jegNJ2fqrJo3AwoV6Y4kLY5FJymm235K3ubitGGmEqbYf9LZcyBvZhwwjUxnjukj H/yA== MIME-Version: 1.0 X-Received: by 10.60.115.103 with SMTP id jn7mr7582111oeb.136.1369304860427; Thu, 23 May 2013 03:27:40 -0700 (PDT) Received: by 10.60.62.146 with HTTP; Thu, 23 May 2013 03:27:40 -0700 (PDT) In-Reply-To: References: Date: Thu, 23 May 2013 11:27:40 +0100 Message-ID: From: Dave Cridland To: "imapext@ietf.org" Content-Type: multipart/alternative; boundary=089e01161b48cbe60e04dd602189 X-Gm-Message-State: ALoCoQmXuHySEF+tBvEs8EcgB719wVnwEkgXA5GrPrgHyfsZgeoHdfgSnYJ7q3LW9y27tfpg8bYR Subject: Re: [imapext] qresync WG adoption call X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 May 2013 10:27:45 -0000 --089e01161b48cbe60e04dd602189 Content-Type: text/plain; charset=ISO-8859-1 On Mon, May 20, 2013 at 7:20 PM, Dave Cridland wrote: > Therefore this constitutes a call for adoption of both documents; reviews > would be very useful at this stage and I'll prod people if there's no > volunteers. > > Given we have only one response (which I can't actually read as being in favour or not), I'm going to repeat this call - we need some noise, in favour or against. Can people say their piece by Monday, please? Thanks, Dave. (as co-chairman) --089e01161b48cbe60e04dd602189 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Mon, May 20, 2013 at 7:20 PM, Dave Cridland <dave@cr= idland.net> wrote:
Therefore this constit= utes a call for adoption of both documents; reviews would be very useful at= this stage and I'll prod people if there's no volunteers.


Given we have o= nly one response (which I can't actually read as being in favour or not= ), I'm going to repeat this call - we need some noise, in favour or aga= inst.

Can people say their piece by Monday, pleas= e?

Thanks,

<= div style>Dave. (as co-chairman)
--089e01161b48cbe60e04dd602189-- From lear@cisco.com Thu May 23 04:12:08 2013 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21AD921F972E for ; Thu, 23 May 2013 04:12:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.431 X-Spam-Level: X-Spam-Status: No, score=-110.431 tagged_above=-999 required=5 tests=[AWL=0.167, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bnrA-yH1Oabb for ; Thu, 23 May 2013 04:12:03 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id 4DC7721F922A for ; Thu, 23 May 2013 04:12:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4103; q=dns/txt; s=iport; t=1369307523; x=1370517123; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=iV8+3fwP12t+OGMkP0p7uH4OTOUMEuNVT1dZqXCnCdc=; b=FD2jImlC9c6zz54453D3+RxNFI7eJMaKThldsw49XxMcPVJwJNsMTy4D 45j3V1CBxYxIjf0ficKK9MyEMH8DkSamyajedOTBHEEe8rMvtlc8UabYK uhIexCARd+7edQ62i0WYd7ZwV240N3Ezhb1rUxj9GhEEt0N9lXdAaky5T A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AssIAP/4nVGQ/khL/2dsb2JhbABagwgwgzuFXrkSgQoWdIIjAQEBBAEBARoGSwYEARAPFAkWCAMCAgkDAgECARUfEQYNAQUCAQGICQyoT5FpBI8dB4JBgRMDlziRQIMROg X-IronPort-AV: E=Sophos;i="4.87,728,1363132800"; d="scan'208,217";a="82788291" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-2.cisco.com with ESMTP; 23 May 2013 11:11:58 +0000 Received: from dhcp-10-61-106-245.cisco.com (dhcp-10-61-106-245.cisco.com [10.61.106.245]) by ams-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r4NBBued022886 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 23 May 2013 11:11:56 GMT Message-ID: <519DF97C.8060500@cisco.com> Date: Thu, 23 May 2013 13:11:56 +0200 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Dave Cridland References: In-Reply-To: X-Enigmail-Version: 1.5.1 Content-Type: multipart/alternative; boundary="------------030704080104060700010405" Cc: "imapext@ietf.org" Subject: [imapext] WG participants please READ Re: qresync WG adoption call X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 May 2013 11:12:08 -0000 This is a multi-part message in MIME format. --------------030704080104060700010405 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit I'm going to echo Dave's point. This organization does its best work when there are many eyes and its worst when people don't pay attention. If this work is important to you, PLEASE take a few minutes to read both documents and comment on this call for adoption. Eliot On 5/23/13 12:27 PM, Dave Cridland wrote: > On Mon, May 20, 2013 at 7:20 PM, Dave Cridland > wrote: > > Therefore this constitutes a call for adoption of both documents; > reviews would be very useful at this stage and I'll prod people if > there's no volunteers. > > > Given we have only one response (which I can't actually read as being > in favour or not), I'm going to repeat this call - we need some noise, > in favour or against. > > Can people say their piece by Monday, please? > > Thanks, > > Dave. (as co-chairman) > > > _______________________________________________ > imapext mailing list > imapext@ietf.org > https://www.ietf.org/mailman/listinfo/imapext --------------030704080104060700010405 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit <co-chair hat on>

I'm going to echo Dave's point.  This organization does its best work when there are many eyes and its worst when people don't pay attention.  If this work is important to you, PLEASE take a few minutes to read both documents and comment on this call for adoption.

Eliot

On 5/23/13 12:27 PM, Dave Cridland wrote:
On Mon, May 20, 2013 at 7:20 PM, Dave Cridland <dave@cridland.net> wrote:
Therefore this constitutes a call for adoption of both documents; reviews would be very useful at this stage and I'll prod people if there's no volunteers.


Given we have only one response (which I can't actually read as being in favour or not), I'm going to repeat this call - we need some noise, in favour or against.

Can people say their piece by Monday, please?

Thanks,

Dave. (as co-chairman)


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

--------------030704080104060700010405-- From adrien@qbik.com Thu May 23 04:16:11 2013 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B77F21F935A for ; Thu, 23 May 2013 04:16:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xQSex3jBhr7J for ; Thu, 23 May 2013 04:16:07 -0700 (PDT) Received: from smtp.qbik.com (smtp.qbik.com [210.55.214.35]) by ietfa.amsl.com (Postfix) with ESMTP id 1195321F95D5 for ; Thu, 23 May 2013 04:16:06 -0700 (PDT) Received: From SCREECH.qbik.local (unverified [192.168.0.4]) by SMTP Server [192.168.0.1] (WinGate SMTP Receiver v8.0.0 (Build 4554)) with SMTP id <0019731411@smtp.qbik.com>; Thu, 23 May 2013 23:16:04 +1200 Received: From [192.168.0.23] (unverified [192.168.0.23]) by SMTP Server [192.168.0.4] (WinGate SMTP Receiver v8.0.0 (Build 4555)) with SMTP id <0000209858@SCREECH.qbik.local>; Thu, 23 May 2013 23:16:03 +1200 From: "Adrien W. de Croy" To: "Eliot Lear" , "Dave Cridland" Date: Thu, 23 May 2013 11:16:03 +0000 Content-Type: multipart/alternative; boundary="------=_MBF8DCE595-A073-4F3C-B33F-E95289CE2051" In-Reply-To: <519DF97C.8060500@cisco.com> Message-Id: Mime-Version: 1.0 User-Agent: eM_Client/5.0.18025.0 Cc: "imapext@ietf.org" Subject: Re: [imapext] WG participants please READ Re: qresync WG adoption call X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: "Adrien W. de Croy" List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 May 2013 11:16:11 -0000 --------=_MBF8DCE595-A073-4F3C-B33F-E95289CE2051 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; format=flowed; charset=utf-8 we already have support for CONDSTORE, but without mainstream client=20 support for QRESYNC (esp with current status of Thunderbird) it's hard=20 to justify the investment (refactoring to allow persistence of=20 information about deleted messages) in that one. So I would be keen to implement it, but I'd want to see some indication=20 that popular clients are going to use it. Also would be great if we could get a universal modseq for the entire=20 user account, so you can query for changed folders. Adrien ------ Original Message ------ From: "Eliot Lear" To: "Dave Cridland" Cc: "imapext@ietf.org" Sent: 23/05/2013 11:11:56 p.m. Subject: [imapext] WG participants please READ Re: qresync WG adoption=20 call > > >I'm going to echo Dave's point. This organization does its best work=20 >when there are many eyes and its worst when people don't pay attention.= =20 > If this work is important to you, PLEASE take a few minutes to read=20 >both documents and comment on this call for adoption. > >Eliot > >On 5/23/13 12:27 PM, Dave Cridland wrote: >>On Mon, May 20, 2013 at 7:20 PM, Dave Cridland =20 >>wrote: >>>Therefore this constitutes a call for adoption of both documents;=20 >>>reviews would be very useful at this stage and I'll prod people if=20 >>>there's no volunteers. >>> >> >>Given we have only one response (which I can't actually read as being=20 >>in favour or not), I'm going to repeat this call - we need some noise,= =20 >>in favour or against. >> >>Can people say their piece by Monday, please? >> >>Thanks, >> >>Dave. (as co-chairman) >> >> >>_______________________________________________ imapext mailing list=20 >>imapext@ietf.orghttps://www.ietf.org/mailman/listinfo/imapext > --------=_MBF8DCE595-A073-4F3C-B33F-E95289CE2051 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
 
we already have support for CONDSTORE, but without mainstream client= support for QRESYNC (esp with current status of Thunderbird) it's hard = to justify the investment (refactoring to allow persistence of information= about deleted messages) in that one.
 
So I would be keen to implement it, but I'd want to see some indicatio= n that popular clients are going to use it.
 
Also would be great if we could get a universal modseq for the entire= user account, so you can query for changed folders.
 
Adrien
 
 
------ Original Message ------
From: "Eliot Lear" <lear@cisco.co= m>
To: "Dave Cridland" <dave@crid= land.net>
Cc: "imapext@ietf.org" <imapext= @ietf.org>
Sent: 23/05/2013 11:11:56 p.m.
Subject: [imapext] WG participants please READ Re: qresync WG adoption= call
<co-= chair hat on>

I'm going to echo Dave's point.  This organiza= tion does its best work when there are many eyes and its worst when people= don't pay attention.  If this work is important to you, PLEASE take= a few minutes to read both documents and comment on this call for adoption= .

Eliot

On 5/23/13 12:27 PM, Dave Cridland wrote:
<= /DIV>
On Mon, May 20, 2013 at 7:20 PM, Dave Cridland <dave@= cridland.net> wrote:
Therefore this constitutes a call for adoption of both documents; revi= ews would be very useful at this stage and I'll prod people if there's no= volunteers.


Given we have only one response (which I can't actually read as being= in favour or not), I'm going to repeat this call - we need some noise, = in favour or against.

Can people say their piece by Monday, please?

Thanks,

Dave. (as co-chairman)


_____=
__________________________________________
imapext mailing list
imapex=
t@ietf.org
https://www.ietf.org/mailman/listinfo/imapext

--------=_MBF8DCE595-A073-4F3C-B33F-E95289CE2051-- From cyrus@daboo.name Thu May 23 06:18:27 2013 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 370A521F93D1 for ; Thu, 23 May 2013 06:18:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9NoPgjSKcSFN for ; Thu, 23 May 2013 06:18:22 -0700 (PDT) Received: from daboo.name (daboo.name [173.13.55.49]) by ietfa.amsl.com (Postfix) with ESMTP id 26C9021F9413 for ; Thu, 23 May 2013 06:18:22 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by daboo.name (Postfix) with ESMTP id 9F77143E40F9; Thu, 23 May 2013 09:18:21 -0400 (EDT) X-Virus-Scanned: amavisd-new at example.com Received: from daboo.name ([127.0.0.1]) by localhost (daboo.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4drmPzg3zkc1; Thu, 23 May 2013 09:18:20 -0400 (EDT) Received: from [10.0.1.11] (unknown [173.13.55.49]) by daboo.name (Postfix) with ESMTPSA id 9068243E40EA; Thu, 23 May 2013 09:18:20 -0400 (EDT) Date: Thu, 23 May 2013 09:18:19 -0400 From: Cyrus Daboo To: Dave Cridland , imapext@ietf.org Message-ID: In-Reply-To: References: X-Mailer: Mulberry/4.1.0a3 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline; size=331 Subject: Re: [imapext] qresync WG adoption call X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 May 2013 13:18:27 -0000 Hi Dave, --On May 20, 2013 7:20:26 PM +0100 Dave Cridland wrote: > We now have two drafts by Alexey published: > > > =C2=A0- draft-melnikov-rfc4551-bis-00 (CONDSTORE) > =C2=A0- draft-melnikov-5162bis-00 (QRESYNC) > > > I'd like to propose that the working group adopt these as our start = point. > +1 --=20 Cyrus Daboo From murch@andrew.cmu.edu Thu May 23 06:22:24 2013 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C185221F9345 for ; Thu, 23 May 2013 06:22:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.995 X-Spam-Level: X-Spam-Status: No, score=-6.995 tagged_above=-999 required=5 tests=[AWL=-0.397, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6eKmhMxgvcJa for ; Thu, 23 May 2013 06:22:17 -0700 (PDT) Received: from smtp.andrew.cmu.edu (SMTP.ANDREW.CMU.EDU [128.2.11.95]) by ietfa.amsl.com (Postfix) with ESMTP id 90C9A21F92F5 for ; Thu, 23 May 2013 06:22:10 -0700 (PDT) Received: from [192.168.137.22] (cpe-76-180-197-142.buffalo.res.rr.com [76.180.197.142]) (user=murch mech=PLAIN (0 bits)) by smtp.andrew.cmu.edu (8.14.4/8.14.4) with ESMTP id r4NDM8BP029291 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Thu, 23 May 2013 09:22:09 -0400 Message-ID: <519E1800.3080504@andrew.cmu.edu> Date: Thu, 23 May 2013 09:22:08 -0400 From: Ken Murchison Organization: Carnegie Mellon University User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130402 Thunderbird/17.0.5 MIME-Version: 1.0 To: imapext@ietf.org References: <14907_1369074042_r4KIKfLI022746_CAKHUCzxM2C4tyVDQfUVVTm2ecXVHLE7pZBAa=7EpmCUv8OQ-jA@mail.gmail.com> In-Reply-To: <14907_1369074042_r4KIKfLI022746_CAKHUCzxM2C4tyVDQfUVVTm2ecXVHLE7pZBAa=7EpmCUv8OQ-jA@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-PMX-Version: 5.5.9.388399, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2011.5.19.222118 X-SMTP-Spam-Clean: 10% ( TO_IN_SUBJECT 0.5, BODYTEXTP_SIZE_3000_LESS 0, BODY_SIZE_1000_LESS 0, BODY_SIZE_2000_LESS 0, BODY_SIZE_300_399 0, BODY_SIZE_5000_LESS 0, BODY_SIZE_7000_LESS 0, NO_URI_FOUND 0, RDNS_GENERIC_POOLED 0, RDNS_POOLED 0, RDNS_RESIDENTIAL 0, RDNS_SUSP 0, RDNS_SUSP_GENERIC 0, RDNS_SUSP_SPECIFIC 0, __BOUNCE_CHALLENGE_SUBJ 0, __BOUNCE_NDR_SUBJ_EXEMPT 0, __CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __MOZILLA_MSGID 0, __RDNS_POOLED_2 0, __SANE_MSGID 0, __TO_MALFORMED_2 0, __TO_NO_NAME 0, __USER_AGENT 0) X-SMTP-Spam-Score: 10% X-Scanned-By: MIMEDefang 2.60 on 128.2.11.95 Subject: Re: [imapext] qresync WG adoption call X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 May 2013 13:22:25 -0000 On 05/20/2013 02:20 PM, Dave Cridland wrote: > Folks, > > We now have two drafts by Alexey published: > > - draft-melnikov-rfc4551-bis-00 (CONDSTORE) > - draft-melnikov-5162bis-00 (QRESYNC) > > I'd like to propose that the working group adopt these as our start point. +1 -- Kenneth Murchison Principal Systems Software Engineer Carnegie Mellon University From tss@iki.fi Thu May 23 13:12:00 2013 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90DF321F9713 for ; Thu, 23 May 2013 13:12:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.299 X-Spam-Level: X-Spam-Status: No, score=-110.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g1t6jb4hhU1v for ; Thu, 23 May 2013 13:11:45 -0700 (PDT) Received: from dovecot.org (dovecot.org [193.210.130.67]) by ietfa.amsl.com (Postfix) with ESMTP id E449321F96CB for ; Thu, 23 May 2013 12:30:10 -0700 (PDT) Received: from [192.168.10.100] (cs27091020.pp.htv.fi [89.27.91.20]) by dovecot.org (Postfix) with ESMTP id B16C21AE835B for ; Thu, 23 May 2013 22:30:08 +0300 (EEST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Timo Sirainen In-Reply-To: Date: Thu, 23 May 2013 22:30:08 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <8EC4F12B-4CD6-4285-8CBE-C3C38AD7AE8B@iki.fi> References: To: "imapext@ietf.org" X-Mailer: Apple Mail (2.1503) Subject: Re: [imapext] qresync WG adoption call X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 May 2013 20:12:00 -0000 On 20.5.2013, at 21.20, Dave Cridland wrote: > Folks, >=20 > We now have two drafts by Alexey published: >=20 > - draft-melnikov-rfc4551-bis-00 (CONDSTORE) > - draft-melnikov-5162bis-00 (QRESYNC) >=20 > I'd like to propose that the working group adopt these as our start = point. OK. > Therefore this constitutes a call for adoption of both documents; = reviews would be very useful at this stage and I'll prod people if = there's no volunteers. I don't think rfc4551-bis has any actual content changes compared to = rfc4551? Some new things that come to my mind: 1. Dovecot doesn't enable modseq tracking until client has requested it = in some way by enabling CONDSTORE or QRESYNC. Until then it says at = SELECT: * OK [NOMODSEQ] No permanent modsequences I know at least one client thought this meant that modseqs couldn't be = used even if CONDSTORE enabling command was used. I'm thinking about = changing this so that highestmodseq is tracked always in any case, but = that's not the easiest change. Anyway, should the -bis RFC mention = something about this? 2. Per-metadata item modseqs. I didn't pay attention to this previously = since I wasn't planning on implementing it anyway. But now looking at = it..: > UNCHANGEDSINCE >=20 > However, if the mod-sequence of any metadata item of the message > is greater than the specified UNCHANGEDSINCE value, then the > requested operation MUST NOT be performed. =85 > Note: A client trying to make an atomic change to the state of a > particular metadata item (or a set of metadata items) should be > prepared to deal with the case when the server returns the MODIFIED > response code if the state of the metadata item being watched = hasn't > changed (but the state of some other metadata item has). This is > necessary, because some servers don't store separate mod-sequences > for different metadata items. The last sentence seems to be somewhat wrong, because that would be = necessary even if the server stores separate mod-sequences. So as far as I see, the only benefit of having per-metadata modseqs = would be for SEARCH MODSEQ? Seems like the document talks about = per-metadata modseqs a bit too much when its usefulness is very limited, = and somehow I doubt there will ever be many server implementations for = it. It talks also about private vs. shared modseqs. I recently had trouble = with figuring out how to do these, since private and shared modseq = counters are stored in completely different places. I ended up simply = incrementing the shared modseq counter to a message every time its = private flag was changed, which isn't ideal of course. Anyway, again = SEARCH exposes this shared vs private difference, but there's no way to = do that with FETCH. So I'm wondering if there's really any benefit in keeping the = per-metadata and shared vs private modseqs functionality in the -bis = RFC? Is anyone ever going to really implement them? Maybe just allow = client to give those parameters and have server ignore them. If the CONDSTORE -bis RFC is trimmed down, it might be useful to merge = it with QRESYNC -bis, but currently I think it's a bit too bloaty. And I = guess it would make it more difficult to figure out which functionality = is CONDSTORE and which is QRESYNC. But maybe it shouldn't even try, and = would assume clients/servers would always implement both = CONDSTORE+QRESYNC?= From tony@att.com Thu May 23 13:21:26 2013 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2D3A21F969F for ; Thu, 23 May 2013 13:21:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1Y8ILOnRydrO for ; Thu, 23 May 2013 13:21:08 -0700 (PDT) Received: from nbfkord-smmo05.seg.att.com (nbfkord-smmo05.seg.att.com [209.65.160.92]) by ietfa.amsl.com (Postfix) with ESMTP id 2BFCE21F97DD for ; Thu, 23 May 2013 12:40:50 -0700 (PDT) Received: from unknown [144.160.20.145] (EHLO mlpd192.enaf.sfdc.sbc.com) by nbfkord-smmo05.seg.att.com(mxl_mta-6.15.0-1) over TLS secured channel with ESMTP id 1c07e915.0.367847.00-179.1027062.nbfkord-smmo05.seg.att.com (envelope-from ); Thu, 23 May 2013 19:40:50 +0000 (UTC) X-MXL-Hash: 519e70c205e5f73d-0010233147a56fa8085c14081ad07191a692faa9 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id r4NJengo004309 for ; Thu, 23 May 2013 15:40:49 -0400 Received: from alpi132.aldc.att.com (alpi132.aldc.att.com [130.8.217.2]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id r4NJekww004303 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 23 May 2013 15:40:47 -0400 Received: from alpi153.aldc.att.com (alpi153.aldc.att.com [130.8.42.31]) by alpi132.aldc.att.com (RSA Interceptor) for ; Thu, 23 May 2013 19:40:37 GMT Received: from aldc.att.com (localhost [127.0.0.1]) by alpi153.aldc.att.com (8.14.5/8.14.5) with ESMTP id r4NJebIe011155 for ; Thu, 23 May 2013 15:40:37 -0400 Received: from mailgw1.maillennium.att.com (maillennium.att.com [135.25.114.99]) by alpi153.aldc.att.com (8.14.5/8.14.5) with ESMTP id r4NJeZ36011113 for ; Thu, 23 May 2013 15:40:36 -0400 Received: from [135.70.84.245] (vpn-135-70-84-245.vpn.swst.att.com[135.70.84.245]) by maillennium.att.com (mailgw1) with ESMTP id <20130523194031gw1008e015e> (Authid: tony); Thu, 23 May 2013 19:40:34 +0000 X-Originating-IP: [135.70.84.245] Message-ID: <519E70AE.5060107@att.com> Date: Thu, 23 May 2013 15:40:30 -0400 From: Tony Hansen User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: "imapext@ietf.org" References: In-Reply-To: X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-RSA-Inspected: yes X-RSA-Classifications: public X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.20.145] X-AnalysisOut: [v=2.0 cv=XPiHv3dE c=1 sm=0 a=ZRNLZ4dFUbCvG8UMqPvVAA==:17 a] X-AnalysisOut: [=CcG6VjeJWIQA:10 a=bfzWQn4VrGAA:10 a=1StAGxjeHgIA:10 a=ofM] X-AnalysisOut: [gfj31e3cA:10 a=BLceEmwcHowA:10 a=8nJEP1OIZ-IA:10 a=zQP7CpK] X-AnalysisOut: [OAAAA:8 a=3NzagTm04LwA:10 a=1Nf1HMoUfQ_6dF8MJZwA:9 a=wPNLv] X-AnalysisOut: [fGTeEIA:10] Subject: Re: [imapext] qresync WG adoption call X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 May 2013 20:21:26 -0000 +1 I also like the idea of a combined document, following Alexey's outlined approach. Tony Hansen On 5/20/2013 2:20 PM, Dave Cridland wrote: > Therefore this constitutes a call for adoption of both documents; > reviews would be very useful at this stage and I'll prod people if > there's no volunteers. From alexey.melnikov@isode.com Thu May 23 14:16:00 2013 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B757221F9607 for ; Thu, 23 May 2013 14:16:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.203 X-Spam-Level: X-Spam-Status: No, score=-101.203 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UfK6pe-9dwhZ for ; Thu, 23 May 2013 14:15:46 -0700 (PDT) Received: from statler.isode.com (statler.isode.com [62.3.217.254]) by ietfa.amsl.com (Postfix) with ESMTP id B84B721F8825 for ; Thu, 23 May 2013 13:32:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1369341137; d=isode.com; s=selector; i=@isode.com; bh=WPYS1tT3yVgDur9aMXj67C58W2x0tp6/gFujMIDYFsQ=; 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=UDe+6I7Fh2wqM7zDJEBfqMpACpaV/t2IGho32sKURXk0LlsNmHMfVUwMljiG0WtNMD0D+C wTwBn7zmM5b50XtRsMUMspVZT5gNCvXZnDey2iCC3v22/6DJSAQPt3OYWnmHQc/Copa8nZ azxhSsjMhn6h1WgYkmsngb+EoHV4K5k=; Received: from [188.30.65.146] (188.30.65.146.threembb.co.uk [188.30.65.146]) by statler.isode.com (submission channel) via TCP with ESMTPSA id ; Thu, 23 May 2013 21:32:17 +0100 References: <8EC4F12B-4CD6-4285-8CBE-C3C38AD7AE8B@iki.fi> In-Reply-To: <8EC4F12B-4CD6-4285-8CBE-C3C38AD7AE8B@iki.fi> Message-Id: X-Mailer: iPad Mail (9B206) From: Alexey Melnikov Date: Thu, 23 May 2013 21:36:00 +0100 To: Timo Sirainen MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Cc: "imapext@ietf.org" Subject: Re: [imapext] qresync WG adoption call X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 May 2013 21:16:00 -0000 On 23 May 2013, at 20:30, Timo Sirainen wrote: > I don't think rfc4551-bis has any actual content changes compared to rfc45= 51? 3 errata are addressed, mostly minor. (I will reply to the rest of your message in a separate email.) From jkt@flaska.net Thu May 23 14:17:11 2013 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD56121F9815 for ; Thu, 23 May 2013 14:17:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cJEskIiD2F0z for ; Thu, 23 May 2013 14:17:01 -0700 (PDT) Received: from latimerie.flaska.net (latimerie.flaska.net [IPv6:2a02:2b88:2:1::4a7:333]) by ietfa.amsl.com (Postfix) with ESMTP id D81C421F9817 for ; Thu, 23 May 2013 13:33:09 -0700 (PDT) Received: by latimerie.flaska.net (Postfix, from userid 1000) id 04CB6610FD; Thu, 23 May 2013 22:33:06 +0200 (CEST) From: =?iso-8859-1?Q?Jan_Kundr=E1t?= To: Date: Thu, 23 May 2013 22:33:06 +0200 User-Agent: trojita/v0.3.93-53-g0979b77; Qt/4.8.4; X11; Linux; MIME-Version: 1.0 Message-ID: <6a18dce6-c858-4c92-936e-b0e91528f20c@flaska.net> In-Reply-To: <8EC4F12B-4CD6-4285-8CBE-C3C38AD7AE8B@iki.fi> References: <8EC4F12B-4CD6-4285-8CBE-C3C38AD7AE8B@iki.fi> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Subject: [imapext] Re: qresync WG adoption call X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 May 2013 21:17:11 -0000 On Thursday, 23 May 2013 21:30:08 CEST, Timo Sirainen wrote:=0A> 1. Dov= ecot doesn't enable modseq tracking until client has =0A> requested it = in some way by enabling CONDSTORE or QRESYNC. Until =0A> then it says a= t SELECT:=0A>=0A> * OK [NOMODSEQ] No permanent modsequences=0A=0AThis i= s probably worth explaining in the updated version. I see the benefits = of not tracking MODSEQs when not ever requested, but I also understand = that clients might want to set a local "don't bother with MODSEQs" bit = in their cache if the server returns a NOMODSEQ. I can also see that a = client might want to open a mailbox and bypass the usual sycnhronizatio= n steps (perhaps it just wants to quickly fetch an item, etc), so the u= se case for a MODSEQ-supporting client not enabling MODSEQs within some= sessions seems valid to me. It's a corner case with potential to cause= unpleasant surprises.=0A=0AOriginally, I wanted to suggest not returni= ng either of HIGHESTMODSEQ or NOMODSEQ at SELECT time, but this is expl= icitly forbidden by the RFC.=0A=0ADo you have any numbers on how much p= erformance is gained by not tracking the MODSEQs -- i.e. is your optimi= zation actually worth the complexity?=0A=0ACheers,=0AJan=0A=0A-- =0ATro= jit=C3=A1, a fast Qt IMAP e-mail client -- http://trojita.flaska.net/ From dave@cridland.net Thu May 23 15:26:21 2013 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D84B21F9940 for ; Thu, 23 May 2013 15:26:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.66 X-Spam-Level: X-Spam-Status: No, score=-0.66 tagged_above=-999 required=5 tests=[AWL=-0.649, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001, SARE_HTML_USL_OBFU=1.666] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2K2RjrsZcFYT for ; Thu, 23 May 2013 15:26:10 -0700 (PDT) Received: from mail-ob0-x229.google.com (mail-ob0-x229.google.com [IPv6:2607:f8b0:4003:c01::229]) by ietfa.amsl.com (Postfix) with ESMTP id 582C721F9180 for ; Thu, 23 May 2013 14:40:11 -0700 (PDT) Received: by mail-ob0-f169.google.com with SMTP id 16so4285186obc.0 for ; Thu, 23 May 2013 14:40:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cridland.net; s=google; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=thcksCcxgg2zAt2SltviJtW/K0JCIbbQUIBbNC8JOUs=; b=TmrXmVSNA4rTHZ2BsP5eUd4RjoQfGtz0POLkSOCeZOvIjjX/VWMtDZVOocdKS/1H/6 I/n/sFdbX+csCfIJ8tGuO7pM28msu2UyZ0x1HONvCzLbTVWGbjvQURn3imeqF/6qKFHG 6wzjJsDJj9k4xpoJ33hCDH1bpHKqkjEcDGekk= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type :x-gm-message-state; bh=thcksCcxgg2zAt2SltviJtW/K0JCIbbQUIBbNC8JOUs=; b=lB8iXWvNJXYLIaqkUX6p6F1PycQ8MizjtVXv9gavwecTz3bvsk6yDwZeallRzJxJUh IOZqXmJL70Ib937uBx7glB5bPFtQhyyR/4xBxNVBvXMQYEQjxImedwXUQLOxPbB0vYe8 N8oLDBkUjFXH/cq9mN+ORhl7/2tIdLvIiOE74e96Q2qUdDNz1D52ZG5tpMMUhp+DjzjF PFkNro0DtTXsZ6PmRL2ztGfjearlzPHqezyzMGcu35UCyNFtkhZIVd6wjbTUB0bylsLU H/9eaU1NsRiMCQARNnQNIuMAn3w9SG/B7QnAU56K2C6CV1yi9TIqEbl4pFNbWk9MtTfn dUXA== MIME-Version: 1.0 X-Received: by 10.182.237.6 with SMTP id uy6mr8305587obc.31.1369345210826; Thu, 23 May 2013 14:40:10 -0700 (PDT) Received: by 10.60.62.146 with HTTP; Thu, 23 May 2013 14:40:10 -0700 (PDT) Received: by 10.60.62.146 with HTTP; Thu, 23 May 2013 14:40:10 -0700 (PDT) Date: Thu, 23 May 2013 22:40:10 +0100 Message-ID: From: Dave Cridland To: =?ISO-8859-1?Q?Jan_Kundr=E1t?= Content-Type: multipart/alternative; boundary=e89a8ff24eafde239c04dd69863e X-Gm-Message-State: ALoCoQla6XQRlYPtjAD20TKAWYrI1DUTuKEvGfcDMUm68WyX5f4xZyBarBndN0JyRA/G6PxZQ3Nl Cc: imapext@ietf.org Subject: [imapext] "NOMODSEQ until needed" optimization X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 May 2013 22:26:21 -0000 --e89a8ff24eafde239c04dd69863e Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable This is a great conversation to be having, but please remember to change the subject line... On 23 May 2013 22:17, "Jan Kundr=E1t" wrote: > On Thursday, 23 May 2013 21:30:08 CEST, Timo Sirainen wrote: > >> 1. Dovecot doesn't enable modseq tracking until client has requested it >> in some way by enabling CONDSTORE or QRESYNC. Until then it says at SELE= CT: >> >> * OK [NOMODSEQ] No permanent modsequences >> > > This is probably worth explaining in the updated version. I see the > benefits of not tracking MODSEQs when not ever requested, but I also > understand that clients might want to set a local "don't bother with > MODSEQs" bit in their cache if the server returns a NOMODSEQ. I can also > see that a client might want to open a mailbox and bypass the usual > sycnhronization steps (perhaps it just wants to quickly fetch an item, > etc), so the use case for a MODSEQ-supporting client not enabling MODSEQs > within some sessions seems valid to me. It's a corner case with potential > to cause unpleasant surprises. > > Originally, I wanted to suggest not returning either of HIGHESTMODSEQ or > NOMODSEQ at SELECT time, but this is explicitly forbidden by the RFC. > > Do you have any numbers on how much performance is gained by not tracking > the MODSEQs -- i.e. is your optimization actually worth the complexity? > > Cheers, > Jan > > -- > Trojit=E1, a fast Qt IMAP e-mail client -- http://trojita.flaska.net/ > ______________________________**_________________ > imapext mailing list > imapext@ietf.org > https://www.ietf.org/mailman/**listinfo/imapext > --e89a8ff24eafde239c04dd69863e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

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

On 23 May 2013 22:17, "Jan Kundr=E1t" = <jkt@flaska.net> wrote:
On Thursday, 23 May 2013 21:30:08 CEST, Timo Sirainen wrote:
1. Dovecot doesn't enable modseq tracking until client has requested it= in some way by enabling CONDSTORE or QRESYNC. Until then it says at SELECT= :

* OK [NOMODSEQ] No permanent modsequences

This is probably worth explaining in the updated version. I see the benefit= s of not tracking MODSEQs when not ever requested, but I also understand th= at clients might want to set a local "don't bother with MODSEQs&qu= ot; bit in their cache if the server returns a NOMODSEQ. I can also see tha= t a client might want to open a mailbox and bypass the usual sycnhronizatio= n steps (perhaps it just wants to quickly fetch an item, etc), so the use c= ase for a MODSEQ-supporting client not enabling MODSEQs within some session= s seems valid to me. It's a corner case with potential to cause unpleas= ant surprises.

Originally, I wanted to suggest not returning either of HIGHESTMODSEQ or NO= MODSEQ at SELECT time, but this is explicitly forbidden by the RFC.

Do you have any numbers on how much performance is gained by not tracking t= he MODSEQs -- i.e. is your optimization actually worth the complexity?

Cheers,
Jan

--
Trojit=E1, a fast Qt IMAP e-mail client -- http://trojita.flaska.net/
_______________________________________________
imapext mailing list
imapext@ietf.org<= br> https://www.ietf.org/mailman/listinfo/imapext
--e89a8ff24eafde239c04dd69863e-- From adrien@qbik.com Thu May 23 15:30:17 2013 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6AFA21F86CE for ; Thu, 23 May 2013 15:30:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=-0.149, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mdi3q4qyz4gx for ; Thu, 23 May 2013 15:30:13 -0700 (PDT) Received: from smtp.qbik.com (smtp.qbik.com [210.55.214.35]) by ietfa.amsl.com (Postfix) with ESMTP id 0EC5721F9782 for ; Thu, 23 May 2013 14:51:39 -0700 (PDT) Received: From SCREECH.qbik.local (unverified [192.168.0.4]) by SMTP Server [192.168.0.1] (WinGate SMTP Receiver v8.0.0 (Build 4554)) with SMTP id <0019732557@smtp.qbik.com>; Fri, 24 May 2013 09:51:32 +1200 Received: From [192.168.0.23] (unverified [192.168.0.23]) by SMTP Server [192.168.0.4] (WinGate SMTP Receiver v8.0.0 (Build 4555)) with SMTP id <0000210240@SCREECH.qbik.local>; Fri, 24 May 2013 09:51:32 +1200 From: "Adrien W. de Croy" To: =?utf-8?q?Jan=20Kundr=c3=a1t?= , "imapext@ietf.org" Date: Thu, 23 May 2013 21:51:32 +0000 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; format=flowed; charset=utf-8 In-Reply-To: <6a18dce6-c858-4c92-936e-b0e91528f20c@flaska.net> Message-Id: Mime-Version: 1.0 User-Agent: eM_Client/5.0.18025.0 Subject: Re: [imapext] qresync WG adoption call X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: "Adrien W. de Croy" List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 May 2013 22:30:17 -0000 are you talking about using the client setting to determine whether the=20 server will track / store modseqs? this seems dangerous. The server never knows when it will be asked by a= =20 client for modseq, so if it supports it, it should track them always. =20 It's common for the same mailbox to be accessed by multiple different=20 agents (e.g. desktop + iOS) As for deprecating shared/private and metadata modseq... +1 Adrien ------ Original Message ------ From: "Jan Kundr=C3=A1t" To: "imapext@ietf.org" Sent: 24/05/2013 8:33:06 a.m. Subject: [imapext] Re: qresync WG adoption call >On Thursday, 23 May 2013 21:30:08 CEST, Timo Sirainen wrote: >>1. Dovecot doesn't enable modseq tracking until client has requested=20 >>it in some way by enabling CONDSTORE or QRESYNC. Until then it says at= =20 >>SELECT: >> >>* OK [NOMODSEQ] No permanent modsequences > >This is probably worth explaining in the updated version. I see the=20 >benefits of not tracking MODSEQs when not ever requested, but I also=20 >understand that clients might want to set a local "don't bother with=20 >MODSEQs" bit in their cache if the server returns a NOMODSEQ. I can=20 >also see that a client might want to open a mailbox and bypass the=20 >usual sycnhronization steps (perhaps it just wants to quickly fetch an=20 >item, etc), so the use case for a MODSEQ-supporting client not enabling= =20 >MODSEQs within some sessions seems valid to me. It's a corner case with= =20 >potential to cause unpleasant surprises. > >Originally, I wanted to suggest not returning either of HIGHESTMODSEQ=20 >or NOMODSEQ at SELECT time, but this is explicitly forbidden by the=20 >RFC. > >Do you have any numbers on how much performance is gained by not=20 >tracking the MODSEQs -- i.e. is your optimization actually worth the=20 >complexity? > >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 jkt@flaska.net Thu May 23 15:33:16 2013 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 602DE21F8648 for ; Thu, 23 May 2013 15:33:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.504 X-Spam-Level: X-Spam-Status: No, score=-1.504 tagged_above=-999 required=5 tests=[AWL=-0.496, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, MISSING_HEADERS=1.292, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3u4wtOhnXQdG for ; Thu, 23 May 2013 15:33:15 -0700 (PDT) Received: from latimerie.flaska.net (latimerie.flaska.net [IPv6:2a02:2b88:2:1::4a7:333]) by ietfa.amsl.com (Postfix) with ESMTP id A7ABD21F9779 for ; Thu, 23 May 2013 15:00:17 -0700 (PDT) Received: by latimerie.flaska.net (Postfix, from userid 1000) id 1C533610FD; Fri, 24 May 2013 00:00:12 +0200 (CEST) From: =?iso-8859-1?Q?Jan_Kundr=E1t?= Cc: Date: Fri, 24 May 2013 00:00:12 +0200 User-Agent: trojita/v0.3.93-53-g0979b77; Qt/4.8.4; X11; Linux; MIME-Version: 1.0 Message-ID: In-Reply-To: References: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Subject: [imapext] Re: qresync WG adoption call X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 May 2013 22:33:16 -0000 On Thursday, 23 May 2013 23:51:32 CEST, Adrien W. de Croy wrote:=0A> ar= e you talking about using the client setting to determine =0A> whether = the server will track / store modseqs?=0A>=0A> this seems dangerous. T= he server never knows when it will be =0A> asked by a client for modseq= , so if it supports it, it should =0A> track them always. It's common = for the same mailbox to be =0A> accessed by multiple different agents (= e.g. desktop + iOS)=0A=0AHi Adrian,=0ADovecot defers creating MODSEQs u= ntil they are "enabled" for a mailbox for the first time. This "enablin= g" happens apparently when the client opens a mailbox after having issu= ed a "CONDSTORE-enabling command" for the first time. This is a safe op= timization -- MODSEQs are turned on as soon as they are required. After= that, they are apparently always tracked even if the user never execut= es a CONDSTORE-enabling command, ever.=0A=0ASome users access their mai= lboxes only from clients which do not issue ENABLE CONDSTORE, ENABLE QR= ESYNC or any other similar command. His point is, apparently, that ther= e is no point in having the MODSEQs tracked under these circumstances. = Unfortunately, they only way to do so under RFC 4551 is rather strange,= via the NOMODSEQ, and some clients are apparently confused by that. I = cannot blame them.=0A=0ACheers,=0AJan=0A=0A-- =0ATrojit=C3=A1, a fast Q= t IMAP e-mail client -- http://trojita.flaska.net/ From tss@iki.fi Thu May 23 15:49:30 2013 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 114D421F96C7 for ; Thu, 23 May 2013 15:49:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.299 X-Spam-Level: X-Spam-Status: No, score=-110.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oZBpB7HFnJ7g for ; Thu, 23 May 2013 15:49:24 -0700 (PDT) Received: from dovecot.org (dovecot.org [193.210.130.67]) by ietfa.amsl.com (Postfix) with ESMTP id 1CE1C21F9403 for ; Thu, 23 May 2013 15:49:23 -0700 (PDT) Received: from [192.168.10.100] (cs27091020.pp.htv.fi [89.27.91.20]) by dovecot.org (Postfix) with ESMTP id A8A071AE8812; Fri, 24 May 2013 01:49:22 +0300 (EEST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Timo Sirainen In-Reply-To: <6a18dce6-c858-4c92-936e-b0e91528f20c@flaska.net> Date: Fri, 24 May 2013 01:49:22 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <8EC4F12B-4CD6-4285-8CBE-C3C38AD7AE8B@iki.fi> <6a18dce6-c858-4c92-936e-b0e91528f20c@flaska.net> To: =?iso-8859-1?Q?Jan_Kundr=E1t?= X-Mailer: Apple Mail (2.1503) Cc: imapext@ietf.org Subject: Re: [imapext] "NOMODSEQ until needed" optimization X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 May 2013 22:49:30 -0000 On 23.5.2013, at 23.33, Jan Kundr=E1t wrote: > On Thursday, 23 May 2013 21:30:08 CEST, Timo Sirainen wrote: >> 1. Dovecot doesn't enable modseq tracking until client has requested = it in some way by enabling CONDSTORE or QRESYNC. Until then it says at = SELECT: >>=20 >> * OK [NOMODSEQ] No permanent modsequences >=20 > Do you have any numbers on how much performance is gained by not = tracking the MODSEQs -- i.e. is your optimization actually worth the = complexity? It's getting less and less useful. Originally when nobody really used = them and Dovecot was using only Maildir, where adding extra 64bits to = each message did about double the (heap) memory usage for a mailbox. But = nowadays other mailbox formats use up more memory already and modseqs = are very useful for other purposes as well (dsync mainly), so they are = getting enabled more and more often anyway. The complexity now would be = to change the code so it wouldn't need to be explicitly enabled :) Mainly I was thinking that the comment in RFC could be about how = NOMODSEQ was already used for this purpose, and/or recommending that if = somebody else plans on doing that they would keep tracking the = highestmodseq regardless of whether per-message modseqs are being = tracked. From alexey.melnikov@isode.com Fri May 24 06:17:30 2013 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5252121F8616 for ; Fri, 24 May 2013 06:17:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.399 X-Spam-Level: X-Spam-Status: No, score=-102.399 tagged_above=-999 required=5 tests=[AWL=0.199, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CH9LlGhPP6Im for ; Fri, 24 May 2013 06:17:29 -0700 (PDT) Received: from waldorf.isode.com (cl-125.lon-03.gb.sixxs.net [IPv6:2a00:14f0:e000:7c::2]) by ietfa.amsl.com (Postfix) with ESMTP id 0EB5D21F85EF for ; Fri, 24 May 2013 06:17:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1369401447; d=isode.com; s=selector; i=@isode.com; bh=pGNbDtPDC2NCfZ1Gw7ZRRkJgvJkoachYU3sxdLIscNc=; 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=vRRo1iEbNPhWjztm41EZJpJvVmMZzO0CyW47stB4D1c/Asg60Vil77zOBOKJ4nz1ZPBYLO MYqzegiIxK4HGykzilQdn5P5d3k/nWuKdOu81TUXhyusCTESpffV8DKYxfHPjbU+LcDUBw ujWQ3l6HiWPTOTquGqYRXSlfmQ3GijQ=; Received: from [172.16.1.29] (shiny.isode.com [62.3.217.250]) by waldorf.isode.com (submission channel) via TCP with ESMTPA id ; Fri, 24 May 2013 14:17:27 +0100 Message-ID: <519F6867.2070401@isode.com> Date: Fri, 24 May 2013 14:17:27 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 To: "Adrien W. de Croy" References: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------020709000106040504040404" Cc: "imapext@ietf.org" , Eliot Lear , Dave Cridland Subject: Re: [imapext] WG participants please READ Re: qresync WG adoption call X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 May 2013 13:17:30 -0000 This is a multi-part message in MIME format. --------------020709000106040504040404 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi Adrien, On 23/05/2013 12:16, Adrien W. de Croy wrote: > we already have support for CONDSTORE, Will you be interested in helping on clarifying/cleaning up the CONDSTORE document? > but without mainstream client support for QRESYNC (esp with current > status of Thunderbird) it's hard to justify the investment > (refactoring to allow persistence of information about deleted > messages) in that one. > So I would be keen to implement it, but I'd want to see some > indication that popular clients are going to use it. I can't tell you about popular clients (Thunderbird, Apple Mail, Windows Live/Outlook). But I know there are several mobile and desktop clients (some of them in development) that make/will make use of QRESYNC. > Also would be great if we could get a universal modseq for the entire > user account, so you can query for changed folders. I think this was discussed before and this looks like another extension. (Several server implementations store per folder modseqs, so it might be a problem for them). > Adrien > ------ Original Message ------ > From: "Eliot Lear" > To: "Dave Cridland" > Cc: "imapext@ietf.org" > Sent: 23/05/2013 11:11:56 p.m. > Subject: [imapext] WG participants please READ Re: qresync WG adoption > call >> >> >> I'm going to echo Dave's point. This organization does its best work >> when there are many eyes and its worst when people don't pay >> attention. If this work is important to you, PLEASE take a few >> minutes to read both documents and comment on this call for adoption. >> >> Eliot >> >> On 5/23/13 12:27 PM, Dave Cridland wrote: >>> On Mon, May 20, 2013 at 7:20 PM, Dave Cridland >>> wrote: >>> >>> Therefore this constitutes a call for adoption of both >>> documents; reviews would be very useful at this stage and I'll >>> prod people if there's no volunteers. >>> >>> >>> Given we have only one response (which I can't actually read as >>> being in favour or not), I'm going to repeat this call - we need >>> some noise, in favour or against. >>> >>> Can people say their piece by Monday, please? >>> >>> Thanks, >>> >>> Dave. (as co-chairman) --------------020709000106040504040404 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Hi Adrien,

On 23/05/2013 12:16, Adrien W. de Croy wrote:
 
we already have support for CONDSTORE,

Will you be interested in helping on clarifying/cleaning up the CONDSTORE document?

but without mainstream client support for QRESYNC (esp with current status of Thunderbird) it's hard to justify the investment (refactoring to allow persistence of information about deleted messages) in that one.
 
So I would be keen to implement it, but I'd want to see some indication that popular clients are going to use it.

I can't tell you about popular clients (Thunderbird, Apple Mail, Windows Live/Outlook). But I know there are several mobile and desktop clients (some of them in development) that make/will make use of QRESYNC.

Also would be great if we could get a universal modseq for the entire user account, so you can query for changed folders.

I think this was discussed before and this looks like another extension. (Several server implementations store per folder modseqs, so it might be a problem for them).

 Adrien
 
 
------ Original Message ------
From: "Eliot Lear" <lear@cisco.com>
To: "Dave Cridland" <dave@cridland.net>
Sent: 23/05/2013 11:11:56 p.m.
Subject: [imapext] WG participants please READ Re: qresync WG adoption call
<co-chair hat on>

I'm going to echo Dave's point.  This organization does its best work when there are many eyes and its worst when people don't pay attention.  If this work is important to you, PLEASE take a few minutes to read both documents and comment on this call for adoption.

Eliot

On 5/23/13 12:27 PM, Dave Cridland wrote:
On Mon, May 20, 2013 at 7:20 PM, Dave Cridland <dave@cridland.net> wrote:
Therefore this constitutes a call for adoption of both documents; reviews would be very useful at this stage and I'll prod people if there's no volunteers.


Given we have only one response (which I can't actually read as being in favour or not), I'm going to repeat this call - we need some noise, in favour or against.

Can people say their piece by Monday, please?

Thanks,

Dave. (as co-chairman)


--------------020709000106040504040404-- From alexey.melnikov@isode.com Fri May 24 06:33:07 2013 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EA7721F92EC for ; Fri, 24 May 2013 06:33:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.282 X-Spam-Level: X-Spam-Status: No, score=-102.282 tagged_above=-999 required=5 tests=[AWL=0.017, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t4w0pv3QNoKP for ; Fri, 24 May 2013 06:33:02 -0700 (PDT) Received: from statler.isode.com (statler.isode.com [62.3.217.254]) by ietfa.amsl.com (Postfix) with ESMTP id 49DD921F89FF for ; Fri, 24 May 2013 06:33:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1369402381; d=isode.com; s=selector; i=@isode.com; bh=w4rgsVpWswn7F2Z+EfnfbXdiPTOUH+imyN9wU9w4nwU=; 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=J52YheRkZ6VlRLqU/fVT/Dq6gmNqUuRe1Y7Bil9s6CxRugK4/x/79fBODAsr62Wg1sWZdN 1QhYmOB+sKn+6mEMpc81hXK1/JwYFaMSpmIybQu/xZV6N6mToA7wIT+nbSv12zkjCNNWLS saPDPVIT63IxVg2vkerRZbyLUJ3y4tw=; Received: from [172.16.1.29] (shiny.isode.com [62.3.217.250]) by statler.isode.com (submission channel) via TCP with ESMTPA id ; Fri, 24 May 2013 14:33:00 +0100 Message-ID: <519F6C0E.3090208@isode.com> Date: Fri, 24 May 2013 14:33:02 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 To: =?ISO-8859-1?Q?Jan_Kundr=E1t?= References: <8EC4F12B-4CD6-4285-8CBE-C3C38AD7AE8B@iki.fi> <6a18dce6-c858-4c92-936e-b0e91528f20c@flaska.net> In-Reply-To: <6a18dce6-c858-4c92-936e-b0e91528f20c@flaska.net> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: quoted-printable Cc: imapext@ietf.org Subject: Re: [imapext] qresync WG adoption call X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 May 2013 13:33:07 -0000 On 23/05/2013 21:33, Jan Kundr=E1t wrote: > On Thursday, 23 May 2013 21:30:08 CEST, Timo Sirainen wrote: >> 1. Dovecot doesn't enable modseq tracking until client has requested=20 >> it in some way by enabling CONDSTORE or QRESYNC. Until then it says=20 >> at SELECT: >> >> * OK [NOMODSEQ] No permanent modsequences > > This is probably worth explaining in the updated version. I see the=20 > benefits of not tracking MODSEQs when not ever requested, but I also=20 > understand that clients might want to set a local "don't bother with=20 > MODSEQs" bit in their cache if the server returns a NOMODSEQ. I can=20 > also see that a client might want to open a mailbox and bypass the=20 > usual sycnhronization steps (perhaps it just wants to quickly fetch an=20 > item, etc), so the use case for a MODSEQ-supporting client not=20 > enabling MODSEQs within some sessions seems valid to me. It's a corner=20 > case with potential to cause unpleasant surprises. I know of a client that sometimes opens mailboxes without enabling=20 CONDSTORE or QRESYNC, especially when a mailbox is opened for the first=20 time. This client might also be confused by this behaviour. On the other hand, the client might ENABLE CONDSTORE unconditionally, so=20 this might not actually be a problem. > Originally, I wanted to suggest not returning either of HIGHESTMODSEQ=20 > or NOMODSEQ at SELECT time, but this is explicitly forbidden by the RFC. > > Do you have any numbers on how much performance is gained by not=20 > tracking the MODSEQs -- i.e. is your optimization actually worth the=20 > complexity? From alexey.melnikov@isode.com Fri May 24 06:51:08 2013 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63E1A21F91CA for ; Fri, 24 May 2013 06:51:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.434 X-Spam-Level: X-Spam-Status: No, score=-102.434 tagged_above=-999 required=5 tests=[AWL=0.164, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y3K-w0GWpc5S for ; Fri, 24 May 2013 06:51:05 -0700 (PDT) Received: from waldorf.isode.com (cl-125.lon-03.gb.sixxs.net [IPv6:2a00:14f0:e000:7c::2]) by ietfa.amsl.com (Postfix) with ESMTP id A387721F95D7 for ; Fri, 24 May 2013 06:51:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1369403463; d=isode.com; s=selector; i=@isode.com; bh=V49bj+8wW0HFdEmzQHPlWhgABhcAjkyaP+HhbI6nIaw=; 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=eBVu5i+x1epauU4Y2kGbF6gbfGNsvlWPwRFzBvNRs214n70p/wdW53VpvUoWFZNolTjZRZ GL/r/i16WGnUTf7lPdy8TObazrf8LTeTS8qPh6d/U8xjZsQxFCYqQfDaPww1llIbBeJ1vI Hc20gXYT6XPwhykdu3VqQ2oES6vd+Po=; Received: from [172.16.1.29] (shiny.isode.com [62.3.217.250]) by waldorf.isode.com (submission channel) via TCP with ESMTPA id ; Fri, 24 May 2013 14:51:03 +0100 Message-ID: <519F7048.5080405@isode.com> Date: Fri, 24 May 2013 14:51:04 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 To: Timo Sirainen References: <8EC4F12B-4CD6-4285-8CBE-C3C38AD7AE8B@iki.fi> In-Reply-To: <8EC4F12B-4CD6-4285-8CBE-C3C38AD7AE8B@iki.fi> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------060808080805070208010208" Cc: "imapext@ietf.org" Subject: Re: [imapext] qresync WG adoption call X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 May 2013 13:51:08 -0000 This is a multi-part message in MIME format. --------------060808080805070208010208 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi Timo, On 23/05/2013 20:30, Timo Sirainen wrote: > On 20.5.2013, at 21.20, Dave Cridland wrote: [...] >> Therefore this constitutes a call for adoption of both documents; reviews would be very useful at this stage and I'll prod people if there's no volunteers. > I don't think rfc4551-bis has any actual content changes compared to rfc4551? Some new things that come to my mind: > > 1. Dovecot doesn't enable modseq tracking until client has requested it in some way by enabling CONDSTORE or QRESYNC. Until then it says at SELECT: > > * OK [NOMODSEQ] No permanent modsequences > > I know at least one client thought this meant that modseqs couldn't be used even if CONDSTORE enabling command was used. I'm thinking about changing this so that highestmodseq is tracked always in any case, but that's not the easiest change. Anyway, should the -bis RFC mention something about this? I do find your use case a bit problematic on the client side, but the document can talk about this. What do you think the advice should be? > 2. Per-metadata item modseqs. I didn't pay attention to this previously since I wasn't planning on implementing it anyway. But now looking at it..: > >> UNCHANGEDSINCE >> >> However, if the mod-sequence of any metadata item of the message >> is greater than the specified UNCHANGEDSINCE value, then the >> requested operation MUST NOT be performed. > ... >> Note: A client trying to make an atomic change to the state of a >> particular metadata item (or a set of metadata items) should be >> prepared to deal with the case when the server returns the MODIFIED >> response code if the state of the metadata item being watched hasn't >> changed (but the state of some other metadata item has). This is >> necessary, because some servers don't store separate mod-sequences >> for different metadata items. > *The last sentence seems to be somewhat wrong, because that would be necessary even if the server stores separate mod-sequences.* > > So as far as I see, the only benefit of having per-metadata modseqs would be for SEARCH MODSEQ? Seems like the document talks about per-metadata modseqs a bit too much when its usefulness is very limited, and somehow I doubt there will ever be many server implementations for it. > > It talks also about private vs. shared modseqs. I recently had trouble with figuring out how to do these, since private and shared modseq counters are stored in completely different places. I ended up simply incrementing the shared modseq counter to a message every time its private flag was changed, which isn't ideal of course. Anyway, again SEARCH exposes this shared vs private difference, Can you explain how SEARCH is doing that? > but there's no way to do that with FETCH. > > So I'm wondering if there's really any benefit in keeping the per-metadata This was done to integrate with the ANNOTATION extension. If people are not interested in doing this, this can be dropped. > and shared vs private modseqs functionality in the -bis RFC? I think this is more of an implementation detail, but we can review what the document says and possibly simplify. > Is anyone ever going to really implement them? Maybe just allow client to give those parameters and have server ignore them. > > If the CONDSTORE -bis RFC is trimmed down, it might be useful to merge it with QRESYNC -bis, but currently I think it's a bit too bloaty. And I guess it would make it more difficult to figure out which functionality is CONDSTORE and which is QRESYNC. I think group commands (or their extensions) into QRESYNC specific and generic CONDSTORE/QRESYNC would make sense. > But maybe it shouldn't even try, and would assume clients/servers would always implement both CONDSTORE+QRESYNC? I think the difference is still important for clients which have to cope with only CONDSTORE being present. While I would love for all servers implementing CONDSTORE to also implement QRESYNC, I expect that to take some time. --------------060808080805070208010208 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Hi Timo,

On 23/05/2013 20:30, Timo Sirainen wrote:
On 20.5.2013, at 21.20, Dave Cridland <dave@cridland.net> wrote:
 [...]
Therefore this constitutes a call for adoption of both documents; reviews would be very useful at this stage and I'll prod people if there's no volunteers.

I don't think rfc4551-bis has any actual content changes compared to rfc4551? Some new things that come to my mind:

1. Dovecot doesn't enable modseq tracking until client has requested it in some way by enabling CONDSTORE or QRESYNC. Until then it says at SELECT:

* OK [NOMODSEQ] No permanent modsequences

I know at least one client thought this meant that modseqs couldn't be used even if CONDSTORE enabling command was used. I'm thinking about changing this so that highestmodseq is tracked always in any case, but that's not the easiest change. Anyway, should the -bis RFC mention something about this?

I do find your use case a bit problematic on the client side, but the document can talk about this. What do you think the advice should be? 

2. Per-metadata item modseqs. I didn't pay attention to this previously since I wasn't planning on implementing it anyway. But now looking at it..:


   UNCHANGEDSINCE <mod-sequence>

      However, if the mod-sequence of any metadata item of the message
      is greater than the specified UNCHANGEDSINCE value, then the
      requested operation MUST NOT be performed.

…

   Note: A client trying to make an atomic change to the state of a
   particular metadata item (or a set of metadata items) should be
   prepared to deal with the case when the server returns the MODIFIED
   response code if the state of the metadata item being watched hasn't
   changed (but the state of some other metadata item has).  This is
   necessary, because some servers don't store separate mod-sequences
   for different metadata items.

The last sentence seems to be somewhat wrong, because that would be necessary even if the server stores separate mod-sequences.

So as far as I see, the only benefit of having per-metadata modseqs would be for SEARCH MODSEQ? Seems like the document talks about per-metadata modseqs a bit too much when its usefulness is very limited, and somehow I doubt there will ever be many server implementations for it.

It talks also about private vs. shared modseqs. I recently had trouble with figuring out how to do these, since private and shared modseq counters are stored in completely different places. I ended up simply incrementing the shared modseq counter to a message every time its private flag was changed, which isn't ideal of course. Anyway, again SEARCH exposes this shared vs private difference,
Can you explain how SEARCH is doing that?
but there's no way to do that with FETCH.

So I'm wondering if there's really any benefit in keeping the per-metadata
This was done to integrate with the ANNOTATION extension. If people are not interested in doing this, this can be dropped.
and shared vs private modseqs functionality in the -bis RFC?

I think this is more of an implementation detail, but we can review what the document says and possibly simplify.

Is anyone ever going to really implement them? Maybe just allow client to give those parameters and have server ignore them.

If the CONDSTORE -bis RFC is trimmed down, it might be useful to merge it with QRESYNC -bis, but currently I think it's a bit too bloaty. And I guess it would make it more difficult to figure out which functionality is CONDSTORE and which is QRESYNC.

I think group commands (or their extensions) into QRESYNC specific and generic CONDSTORE/QRESYNC would make sense.

But maybe it shouldn't even try, and would assume clients/servers would always implement both CONDSTORE+QRESYNC?

I think the difference is still important for clients which have to cope with only CONDSTORE being present. While I would love for all servers implementing CONDSTORE to also implement QRESYNC, I expect that to take some time.

--------------060808080805070208010208-- From adrien@qbik.com Sat May 25 15:55:33 2013 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 744A121F8C1A for ; Sat, 25 May 2013 15:55:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.523 X-Spam-Level: X-Spam-Status: No, score=-2.523 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uGxaAXRL5A-b for ; Sat, 25 May 2013 15:55:28 -0700 (PDT) Received: from smtp.qbik.com (smtp.qbik.com [210.55.214.35]) by ietfa.amsl.com (Postfix) with ESMTP id DB45221F8717 for ; Sat, 25 May 2013 15:55:27 -0700 (PDT) Received: From SCREECH.qbik.local (unverified [192.168.0.4]) by SMTP Server [192.168.0.1] (WinGate SMTP Receiver v8.0.0 (Build 4556)) with SMTP id <0019736113@smtp.qbik.com>; Sun, 26 May 2013 10:55:25 +1200 Received: From [192.168.0.23] (unverified [192.168.0.23]) by SMTP Server [192.168.0.4] (WinGate SMTP Receiver v8.0.0 (Build 4555)) with SMTP id <0000211693@SCREECH.qbik.local>; Sun, 26 May 2013 10:55:23 +1200 From: "Adrien W. de Croy" To: "Alexey Melnikov" Date: Sat, 25 May 2013 22:55:22 +0000 Content-Type: multipart/alternative; boundary="------=_MB328AE480-3781-4BB7-BF70-56E1F359175E" In-Reply-To: <519F6867.2070401@isode.com> Message-Id: Mime-Version: 1.0 User-Agent: eM_Client/5.0.18025.0 Cc: Eliot Lear , "imapext@ietf.org" , Dave Cridland Subject: Re: [imapext] WG participants please READ Re: qresync WG adoption call X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: "Adrien W. de Croy" List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 May 2013 22:55:33 -0000 --------=_MB328AE480-3781-4BB7-BF70-56E1F359175E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; format=flowed; charset=utf-8 Hi Alexey ------ Original Message ------ From: "Alexey Melnikov" To: "Adrien W. de Croy" Cc: "imapext@ietf.org" ; "Eliot Lear"=20 ; "Dave Cridland" Sent: 25/05/2013 1:17:27 a.m. Subject: Re: [imapext] WG participants please READ Re: qresync WG=20 adoption call >Hi Adrien, > >On 23/05/2013 12:16, Adrien W. de Croy wrote: >>#03f8d723c825408abd7c65fe8494e360 BLOCKQUOTE.cite {PADDING-LEFT: 10px;= =20 >>MARGIN-LEFT: 5px; BORDER-LEFT: #000000 1px solid; PADDING-RIGHT: 0px;=20 >>MARGIN-RIGHT: 0px} #03f8d723c825408abd7c65fe8494e360 .plain PRE,=20 >>.plain TT {FONT-SIZE: 100%; FONT-FAMILY: monospace; FONT-WEIGHT:=20 >>normal; FONT-STYLE: normal} #03f8d723c825408abd7c65fe8494e360,=20 >>03f8d723c825408abd7c65fe8494e360 .plain PRE, .plain TT {FONT-SIZE:=20 >>12pt; FONT-FAMILY: Tahoma} >> >>we already have support for CONDSTORE, > >Will you be interested in helping on clarifying/cleaning up the=20 >CONDSTORE document? I'd be interested but I don't have much spare bandwidth at the moment. =20 What did you have in mind? It was a while ago that we implemented=20 CONDSTORE, and I don't recall finding any issues with the RFC at the=20 time. However we only looked at it hard enough for our implementation. > > >>but without mainstream client support for QRESYNC (esp with current=20 >>status of Thunderbird) it's hard to justify the investment=20 >>(refactoring to allow persistence of information about deleted=20 >>messages) in that one. >> >>So I would be keen to implement it, but I'd want to see some=20 >>indication that popular clients are going to use it. > >I can't tell you about popular clients (Thunderbird, Apple Mail,=20 >Windows Live/Outlook). But I know there are several mobile and desktop=20 >clients (some of them in development) that make/will make use of=20 >QRESYNC. is anyone on this list a maintainer of thunderbird? > > >>Also would be great if we could get a universal modseq for the entire=20 >>user account, so you can query for changed folders. > >I think this was discussed before and this looks like another=20 >extension. (Several server implementations store per folder modseqs, so= =20 >it might be a problem for them). we use per-folder modseq I'm pretty sure. But could overlay another one= =20 I guess. When you have 500 folders or more, it's a real problem when one agent=20 filters mail, for another agent to discover this. At the moment the=20 agents need to iterate all folders to discover where the mail has gone. In general, compared to messages, folders in IMAP are IMO second class=20 citizens. No way to advertise folder deletion, renaming etc. What could be interesting would be a virtual/meta-folder called=20 "FOLDERS", which treats every folder as a record in this virtual folder.= =20 Then you could just do a modseq on this. Again, out of scope for this. Adrien > > >> Adrien >> >> >>------ Original Message ------ >>From: "Eliot Lear" mailto:lear@cisco.com >>To: "Dave Cridland" mailto:dave@cridland.net >>Cc: mailto:imapext@ietf.orgmailto:imapext@ietf.org >>Sent: 23/05/2013 11:11:56 p.m. >>Subject: [imapext] WG participants please READ Re: qresync WG adoption= =20 >>call >>> >>> >>>I'm going to echo Dave's point. This organization does its best work= =20 >>>when there are many eyes and its worst when people don't pay=20 >>>attention. If this work is important to you, PLEASE take a few=20 >>>minutes to read both documents and comment on this call for adoption. >>> >>>Eliot >>> >>>On 5/23/13 12:27 PM, Dave Cridland wrote: >>>>On Mon, May 20, 2013 at 7:20 PM, Dave Cridland=20 >>>>mailto:dave@cridland.net wrote: >>>>>Therefore this constitutes a call for adoption of both documents;=20 >>>>>reviews would be very useful at this stage and I'll prod people if=20 >>>>>there's no volunteers. >>>>> >>>> >>>>Given we have only one response (which I can't actually read as=20 >>>>being in favour or not), I'm going to repeat this call - we need=20 >>>>some noise, in favour or against. >>>> >>>>Can people say their piece by Monday, please? >>>> >>>>Thanks, >>>> >>>>Dave. (as co-chairman) > > --------=_MB328AE480-3781-4BB7-BF70-56E1F359175E Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Hi Alexey
 
 
------ Original Message ------
From: "Alexey Melnikov" <alexey.melnikov@isode.com>
To: "Adrien W. de Croy" <adrien@= qbik.com>
Cc: "imapext@ietf.org" <imapext= @ietf.org>; "Eliot Lear" <lear@= cisco.com>; "Dave Cridland" <dave@cridland.net>
Sent: 25/05/2013 1:17:27 a.m.
Subject: Re: [imapext] WG participants please READ Re: qresync WG adop= tion call
Hi Adrien,

On 23/05/2013 12:16, Adrien= W. de Croy wrote:
 
we already have support for CONDSTORE,

Will you= be interested in helping on clarifying/cleaning up the CONDSTORE document?=
I'd be interested but I don't have much spare bandwidth at the moment.=   What did you have in mind?  It was a while ago that we implemen= ted CONDSTORE, and I don't recall finding any issues with the RFC at the= time.
 
However we only looked at it hard enough for our implementation.
 

but without mainstream client support for QRESYNC (esp with current= status of Thunderbird) it's hard to justify the investment (refactoring= to allow persistence of information about deleted messages) in that one.
 
So I would be keen to implement it, but I'd want to see some indicatio= n that popular clients are going to use it.

I can't= tell you about popular clients (Thunderbird, Apple Mail, Windows Live/Outl= ook). But I know there are several mobile and desktop clients (some of them= in development) that make/will make use of QRESYNC.
is anyone on this list a maintainer of thunderbird?
 
 

Also would be great if we could get a universal modseq for the entire= user account, so you can query for changed folders.

= I think this was discussed before and this looks like another extension.= (Several server implementations store per folder modseqs, so it might be= a problem for them).
we use per-folder modseq I'm pretty sure.  But could overlay anot= her one I guess.
 
When you have 500 folders or more, it's a real problem when one agent= filters mail, for another agent to discover this.  At the moment the= agents need to iterate all folders to discover where the mail has gone.
 
In general, compared to messages, folders in IMAP are IMO second class= citizens.  No way to advertise folder deletion, renaming etc.
 
What could be interesting would be a virtual/meta-folder called "FOLDE= RS", which treats every folder as a record in this virtual folder. = Then you could just do a modseq on this.
 
Again, out of scope for this.
 
Adrien
 

 Adrien
 
 
------ Original Message ------
From: "Eliot Lear" mailto:lear@cisco.com
To: "Dave Cridland" mailto:dave@cridland.net
Cc: mailto:imapext@ietf.org mailto:imap= ext@ietf.org
Sent: 23/05/2013 11:11:56 p.m.
Subject: [imapext] WG participants please READ Re: qresync WG adoption= call
<co-= chair hat on>

I'm going to echo Dave's point.  This organiza= tion does its best work when there are many eyes and its worst when people= don't pay attention.  If this work is important to you, PLEASE take= a few minutes to read both documents and comment on this call for adoption= .

Eliot

On 5/23/13 12:27 PM, Dave Cridland wrote:
<= /DIV>
On Mon, May 20, 2013 at 7:20 PM, Dave Cridland mail= to:dave@cridland.net wrote:
Therefore this constitutes a call for adoption of both documents; revi= ews would be very useful at this stage and I'll prod people if there's no= volunteers.


Given we have only one response (which I can't actually read as being= in favour or not), I'm going to repeat this call - we need some noise, = in favour or against.

Can people say their piece by Monday, please?

Thanks,

Dave. (as co-chairman)


--------=_MB328AE480-3781-4BB7-BF70-56E1F359175E-- From tss@iki.fi Sat May 25 17:33:48 2013 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18EAD21F8B98 for ; Sat, 25 May 2013 17:33:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.449 X-Spam-Level: X-Spam-Status: No, score=-110.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VE6O+xn84MTV for ; Sat, 25 May 2013 17:33:42 -0700 (PDT) Received: from dovecot.org (dovecot.org [193.210.130.67]) by ietfa.amsl.com (Postfix) with ESMTP id E514621F8899 for ; Sat, 25 May 2013 17:33:40 -0700 (PDT) Received: from [192.168.10.100] (cs27091020.pp.htv.fi [89.27.91.20]) by dovecot.org (Postfix) with ESMTP id DFF501AE8775; Sun, 26 May 2013 03:33:38 +0300 (EEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Timo Sirainen In-Reply-To: Date: Sun, 26 May 2013 03:33:38 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: "Adrien W. de Croy" X-Mailer: Apple Mail (2.1503) Cc: Alexey Melnikov , "imapext@ietf.org" , Eliot Lear , Dave Cridland Subject: Re: [imapext] WG participants please READ Re: qresync WG adoption call X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 May 2013 00:33:48 -0000 On 26.5.2013, at 1.55, Adrien W. de Croy wrote: >>> but without mainstream client support for QRESYNC (esp with current = status of Thunderbird) it's hard to justify the investment (refactoring = to allow persistence of information about deleted messages) in that one. >>> =20 >>> So I would be keen to implement it, but I'd want to see some = indication that popular clients are going to use it. >>=20 >> I can't tell you about popular clients (Thunderbird, Apple Mail, = Windows Live/Outlook). But I know there are several mobile and desktop = clients (some of them in development) that make/will make use of = QRESYNC. > is anyone on this list a maintainer of thunderbird? Unfortunately it looks like Thunderbird won't be implementing any new = features anytime soon. I know there's a patch for SPECIAL-USE already = done, but they won't merge that. >>> Also would be great if we could get a universal modseq for the = entire user account, so you can query for changed folders. >>=20 >> I think this was discussed before and this looks like another = extension. (Several server implementations store per folder modseqs, so = it might be a problem for them). > we use per-folder modseq I'm pretty sure. But could overlay another = one I guess. > =20 > When you have 500 folders or more, it's a real problem when one agent = filters mail, for another agent to discover this. At the moment the = agents need to iterate all folders to discover where the mail has gone. Clients can find out folders that have changed since the last time by = keeping track of their HIGHESTMODSEQ. With LIST-STATUS extension it = could be done with one command. Yeah, requires a bit more effort than a = single global HIGHESTMODSEQ, but I think it's good enough. Also for = active sessions there is the possibility of using NOTIFY.. > In general, compared to messages, folders in IMAP are IMO second class = citizens. No way to advertise folder deletion, renaming etc. > =20 > What could be interesting would be a virtual/meta-folder called = "FOLDERS", which treats every folder as a record in this virtual folder. = Then you could just do a modseq on this. I've solved this internally in Dovecot by giving a GUID for each = mailbox, which allows tracking renames and deletions. Mails also have = GUIDs. I wonder if clients would be interested in having a standard GUID = extension for these.. > Again, out of scope for this. Yeah. From alexey.melnikov@isode.com Sun May 26 04:21:43 2013 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56C0421F8FF8 for ; Sun, 26 May 2013 04:21:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.203 X-Spam-Level: X-Spam-Status: No, score=-101.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SE6YecGOyePD for ; Sun, 26 May 2013 04:21:42 -0700 (PDT) Received: from waldorf.isode.com (cl-125.lon-03.gb.sixxs.net [IPv6:2a00:14f0:e000:7c::2]) by ietfa.amsl.com (Postfix) with ESMTP id 0101421F8FBA for ; Sun, 26 May 2013 04:21:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1369567299; d=isode.com; s=selector; i=@isode.com; bh=x32MX9hAGWSLJYhSdRhMRrbjGSjmWn685kiJY4vSzEM=; 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=r9aFRm+ymXvQk92wRp+nz11JA0/mxRtm1i+pJ582blKJIdlmsTxIVWUKd35B9y2dw4nKx5 ARdfSEJT+ez+jJn4Cwv/sC7JvleDadpRJ6UcMv9jBJTbe8X244bu6oO8T2GoGxwEJKBUHw B0MPIlb/WbjYDa8sbzHKITbOinyHK88=; Received: from [192.168.1.2] (ppp95-165-109-149.pppoe.spdop.ru [95.165.109.149]) by waldorf.isode.com (submission channel) via TCP with ESMTPSA id ; Sun, 26 May 2013 12:21:39 +0100 References: In-Reply-To: Message-Id: X-Mailer: iPad Mail (9B206) From: Alexey Melnikov Date: Sun, 26 May 2013 12:25:29 +0100 To: Timo Sirainen , "Adrien W. de Croy" MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: "imapext@ietf.org" Subject: Re: [imapext] WG participants please READ Re: qresync WG adoption call X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 May 2013 11:21:43 -0000 On 26 May 2013, at 01:33, Timo Sirainen wrote: >> In general, compared to messages, folders in IMAP are IMO second class ci= tizens. No way to advertise folder deletion, renaming etc. >>=20 >> What could be interesting would be a virtual/meta-folder called "FOLDERS"= , which treats every folder as a record in this virtual folder. Then you co= uld just do a modseq on this. >=20 > I've solved this internally in Dovecot by giving a GUID for each mailbox, w= hich allows tracking renames and deletions. Mails also have GUIDs. I wonder i= f clients would be interested in having a standard GUID extension for these.= . I would be happy to look a this/participate in discussions, especially if so= mebody writes a draft. But can I please ask people to concentrate on 1 thing at a time? I would lik= e to finish QRESYNC update this summer, if possible. >> Again, out of scope for this. >=20 > Yeah. From slusarz@horde.org Sun May 26 21:53:27 2013 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8886921F92F5 for ; Sun, 26 May 2013 21:53:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.162 X-Spam-Level: ** X-Spam-Status: No, score=2.162 tagged_above=-999 required=5 tests=[FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iiGM6ZgrVXZ1 for ; Sun, 26 May 2013 21:53:21 -0700 (PDT) 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 CCD3921F92EB for ; Sun, 26 May 2013 21:53:18 -0700 (PDT) Received: from omta14.emeryville.ca.mail.comcast.net ([76.96.30.60]) by qmta08.emeryville.ca.mail.comcast.net with comcast id gskq1l0031HpZEsA8stJJz; Mon, 27 May 2013 04:53:18 +0000 Received: from bigworm.curecanti.org ([71.229.167.0]) by omta14.emeryville.ca.mail.comcast.net with comcast id gstG1l00N00qwSn8astH9x; Mon, 27 May 2013 04:53:18 +0000 Received: from localhost (localhost.localdomain [IPv6:::1]) (Authenticated sender: slusarz) by bigworm.curecanti.org (Postfix) with ESMTPSA id 14D1368068 for ; Sun, 26 May 2013 22:53:16 -0600 (MDT) Received: from blanca.dhcp.curecanti.org (blanca.dhcp.curecanti.org [172.18.5.27]) by bigworm.curecanti.org (Horde Framework) with HTTP; Sun, 26 May 2013 22:53:15 -0600 Date: Sun, 26 May 2013 22:53:15 -0600 Message-ID: <20130526225315.Horde.qC3_BXKNy2RSyFJxAo4X9A7@bigworm.curecanti.org> From: Michael M Slusarz To: imapext@ietf.org References: In-Reply-To: User-Agent: Internet Messaging Program (IMP) H5 (6.1.0-git) Accept-Language: en X-Originating-IP: 172.18.5.27 X-Remote-Browser: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:21.0) Gecko/20100101 Firefox/21.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=1369630398; bh=0BWOLDtpXV12onqEiqpW2lfVgGSwmDGTWl+Iq4ed6gY=; h=Received:Received:Received:Received:Date:Message-ID:From:To: Subject:Content-Type:MIME-Version; b=cxrKwyR07VvCgJ9GbEIDSwk+Zt/lG0GA4l5W2T/sa7uI5viYLI3PRb4Tg0TlkYNjA NtPI555/0PdGMihTaR8lXkV6GX6oIaBybpcUxuEaAT0NomGS6gBt4EHs3R5yPB/shj I5xT87YCFmNA1Zv6z8W7HrWqHEYYrFhOw9bTv6+uutyjgD+8XlaUSw9ZeQgSbAQKxt xX+AKHy+57mnGOuoFUu2qWDJZc6ajLzTDT/XfBb9pgKA/haSoQ/KfnRsHJQxqT6MXI Q0GMxCCTBe4h9DSOWJsFytYBQt7hXgXaD1Jl+llcwB2wp3P7+OnHD1c9ajQaW9VkcK 0UZCNgLuAlq4g== Subject: Re: [imapext] WG participants please READ Re: qresync WG adoption call X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 May 2013 04:53:27 -0000 Quoting "Adrien W. de Croy" : > we already have support for CONDSTORE, but without mainstream client > support for QRESYNC (esp with current status of Thunderbird) it's > hard to justify the investment (refactoring to allow persistence of > information about deleted messages) in that one. > > So I would be keen to implement it, but I'd want to see some > indication that popular clients are going to use it. As someone who implemented a CONDSTORE client first, and then added QRESYNC support (albeit both were 4 years ago), my experience is that it is an incremental improvement. Meaning the learning curve between the two is drastically flatter. It is why I brought up the issue of combining the documents at some point, since -- again, with my client-side implementer cap on -- it would have been preferable to have it all in a single location. As mentioned, not super-relevant at the present time as this can be discussed later. Those documents seem like appropriate starting points to me. Note: I noticed RFC 5162 has a bis-01 version but the original thread e-mail refers to bis-00. What follows is off the top of my head experiences that may be useful to address in some fashion. I believe they are all QRESYNC specific. Might be premature, but figured its better to speak sooner than later: + My main wish list request for QRESYNC support would be to mandate VANISHED responses on QRESYNC enabling. It looks like the draft is leaning in that direction, at least according to a text placeholder. + From recent discussions on one of the IMAP lists somewhere, I recall discussion about the proper ENABLED response when doing a ENABLE QRESYNC command - e.g. 1 ENABLE QRESYNC * ENABLED QRESYNC -or- * ENABLED QRESYNC CONDSTORE 1 OK Might be useful to clarify this. + A reminder of command length limitations and/or a defined command length limitation for QRESYNC commands since a QRESYNC SELECT/EXAMINE can easily contain 1000's of bytes of UID and/or sequence data. Unlike commands like FETCH/STORE, which can be split and pipelined, the ~1000 byte limitation in RFC 2683 doesn't scale well and can't easily be worked around. Obviously you can compress sequence strings by converting into broader ranges, but this can result into a bunch of unneeded data being returned. + The text regarding VANISHED results is confusing. Specifically the fact that servers are allowed to "checkpoint" modseq data to limit storage size. i.e. the first time you see something like this: 1 UID FETCH 1:* (UID) (CHANGEDSINCE 50000 VANISHED) 1 OK 2 UID STORE 10000 +FLAGS \deleted * 1 FETCH (UID 10000 MODSEQ (50001) FLAGS (\Deleted)) 2 OK 3 UID EXPUNGE 10000 * VANISHED 10000 3 OK [HIGHESTMODSEQ 50002] 4 UID FETCH 1:* (UID) (CHANGEDSINCE 50000 VANISHED) * VANISHED (EARLIER) 1:10000 4 OK Perfectly valid server response, but surprising the first time you run into something like it. michael ___________________________________ Michael Slusarz [slusarz@horde.org] From dave@cridland.net Tue May 28 03:42:58 2013 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3A7A21F9681 for ; Tue, 28 May 2013 03:42:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iKOTFiJxWIPm for ; Tue, 28 May 2013 03:42:58 -0700 (PDT) Received: from mail-ob0-x22c.google.com (mail-ob0-x22c.google.com [IPv6:2607:f8b0:4003:c01::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 4DF3A21F9680 for ; Tue, 28 May 2013 03:42:58 -0700 (PDT) Received: by mail-ob0-f172.google.com with SMTP id tb18so8890240obb.17 for ; Tue, 28 May 2013 03:42:57 -0700 (PDT) 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=Tg/Zvww83Q+dUNP1SJvIwNFyNu2/8ALYkjaNDM/ZLwg=; b=D0kHIvQShMj9BLtfv817uYbgpRI5O4rXffmkZrQGr1NeznovokEvJBgIkMsZanUdHi 13gmzbWk32D0/ur2wG+TMvPwKvRwsRGZE8ROC3Bf/og4tQCNYm7VhKgeHo+zdB5rP8io EvU8wWcySJ1t0m6Y9BscLLF7xTOpOpqWRJbGE= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type :x-gm-message-state; bh=Tg/Zvww83Q+dUNP1SJvIwNFyNu2/8ALYkjaNDM/ZLwg=; b=b/3HhytOxfsgaCVI7FVBiOaY2q9nhBYgI1vrBpeUbvflQFWPXcTOQ2Y4AeQKquxRMR n/ye4qmYWU1pKHOHQJBrLEWD3C90iLPckS1fj+6V+mGgLuraNjdRGaVwSirp7L6PKmpV l5PYqk2t7yKp1ZI2OTS2OHawRaDH34f4UOnfX5hix2dgC+JMWUTJVmcYN4R92NAeY/r7 gwD4Cp4p1aVy7PbQbZ5H/FER7gB3c1ubR72bHHSgxSmxKLoHRia9GSNP149n6MMBSJqo 0wi2WIwb6VaqiBng+r3MuxRimXhJUkP0R/gRoRlaWDRpB7ltnnwBWMUEdWOcqwcqJrvH L68Q== MIME-Version: 1.0 X-Received: by 10.182.66.170 with SMTP id g10mr5290132obt.64.1369737777649; Tue, 28 May 2013 03:42:57 -0700 (PDT) Received: by 10.60.62.146 with HTTP; Tue, 28 May 2013 03:42:57 -0700 (PDT) Date: Tue, 28 May 2013 11:42:57 +0100 Message-ID: From: Dave Cridland To: "imapext@ietf.org" Content-Type: multipart/alternative; boundary=001a11c1ed8aac96b904ddc4edb6 X-Gm-Message-State: ALoCoQnnj6zPzmSZYqLfBTT+eFQQEW2fL4FAgQD4j78MQr4kEvJWN5jLfoCSxPkWmg9l3bc+PUKV Subject: [imapext] WG Document Adoption X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 May 2013 10:42:58 -0000 --001a11c1ed8aac96b904ddc4edb6 Content-Type: text/plain; charset=ISO-8859-1 I saw nobody opposed, and plenty for. We'll sort out the mechanics of the adoption now. (Well, probably Eliot, rather than me). Dave. --001a11c1ed8aac96b904ddc4edb6 Content-Type: text/html; charset=ISO-8859-1
I saw nobody opposed, and plenty for.

We'll sort out the mechanics of the adoption now. (Well, probably Eliot, rather than me).

Dave.
--001a11c1ed8aac96b904ddc4edb6-- From internet-drafts@ietf.org Thu May 30 10:38:48 2013 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8A4E21F93D1; Thu, 30 May 2013 10:38:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.508 X-Spam-Level: X-Spam-Status: No, score=-102.508 tagged_above=-999 required=5 tests=[AWL=0.092, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UBuaz3QCFbD3; Thu, 30 May 2013 10:38:48 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 622F421F91CE; Thu, 30 May 2013 10:38:46 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.50 Message-ID: <20130530173846.6611.68852.idtracker@ietfa.amsl.com> Date: Thu, 30 May 2013 10:38:46 -0700 Cc: imapext@ietf.org Subject: [imapext] I-D Action: draft-ietf-qresync-rfc5162bis-00.txt X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 May 2013 17:38:49 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the IMAP QRESYNC Extension Working Group of t= he IETF. Title : IMAP4 Extensions for Quick Mailbox Resynchronization Author(s) : Alexey Melnikov Dave Cridland Filename : draft-ietf-qresync-rfc5162bis-00.txt Pages : 25 Date : 2013-05-30 Abstract: This document defines an IMAP4 extension, which gives an IMAP client the ability to quickly resynchronize any previously opened mailbox as part of the SELECT command, without the need for server-side state or additional client round-trips. This extension also introduces a new response that allows for a more compact representation of a list of expunged messages (and always includes the Unique Identifiers (UIDs) expunged). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-qresync-rfc5162bis There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-qresync-rfc5162bis-00 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From internet-drafts@ietf.org Thu May 30 10:39:12 2013 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5867A21F9603; Thu, 30 May 2013 10:39:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.515 X-Spam-Level: X-Spam-Status: No, score=-102.515 tagged_above=-999 required=5 tests=[AWL=0.085, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UBpujHa0WoQE; Thu, 30 May 2013 10:39:11 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D9CD021F93D1; Thu, 30 May 2013 10:39:11 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.50 Message-ID: <20130530173911.13728.48974.idtracker@ietfa.amsl.com> Date: Thu, 30 May 2013 10:39:11 -0700 Cc: imapext@ietf.org Subject: [imapext] I-D Action: draft-ietf-qresync-rfc4551bis-00.txt X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 May 2013 17:39:12 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the IMAP QRESYNC Extension Working Group of t= he IETF. Title : IMAP Extension for Conditional STORE Operation or Quick = Flag Changes Resynchronization Author(s) : Alexey Melnikov Filename : draft-ietf-qresync-rfc4551bis-00.txt Pages : 24 Date : 2013-05-30 Abstract: Often, multiple IMAP (RFC 3501) clients need to coordinate changes to a common IMAP mailbox. Examples include different clients working on behalf of the same user, and multiple users accessing shared mailboxes. These clients need a mechanism to synchronize state changes for messages within the mailbox. They must be able to guarantee that only one client can change message state (e.g., message flags) at any time. An example of such an application is use of an IMAP mailbox as a message queue with multiple dequeueing clients. The Conditional Store facility provides a protected update mechanism for message state information that can detect and resolve conflicts between multiple writing mail clients. The Conditional Store facility also allows a client to quickly resynchronize mailbox flag changes. This document defines an extension to IMAP (RFC 3501). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-qresync-rfc4551bis There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-qresync-rfc4551bis-00 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From atlauren@me.com Fri May 31 15:19:31 2013 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F11021F8FDC for ; Fri, 31 May 2013 15:19:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.184 X-Spam-Level: X-Spam-Status: No, score=-4.184 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zm1DFq+OXKhw for ; Fri, 31 May 2013 15:19:25 -0700 (PDT) Received: from st11p01mm-asmtp001.mac.com (st11p01mm-asmtp001.mac.com [17.172.204.236]) by ietfa.amsl.com (Postfix) with ESMTP id 21EBF21F8FF3 for ; Fri, 31 May 2013 15:19:18 -0700 (PDT) Received: from st11p01mm-spool002.mac.com ([17.172.204.247]) by st11p01mm-asmtp001.mac.com (Oracle Communications Messaging Server 7u4-27.05(7.0.4.27.4) 64bit (built Apr 23 2013)) with ESMTP id <0MNO0051DON6OR10@st11p01mm-asmtp001.mac.com> for imapext@ietf.org; Fri, 31 May 2013 22:18:43 +0000 (GMT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.10.8626,1.0.431,0.0.0000 definitions=2013-05-31_09:2013-05-31, 2013-05-31, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=6.0.2-1305010000 definitions=main-1305310233 MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_vN/NzFHg5hWwSvkg4zKs3w)" Received: from localhost ([17.172.205.17]) by st11p01mm-spool002.mac.com (Oracle Communications Messaging Server 7u4-23.01(7.0.4.23.0) 64bit (built Aug 10 2011)) with ESMTP id <0MNO00135ON6H6A0@st11p01mm-spool002.mac.com>; Fri, 31 May 2013 22:18:42 +0000 (GMT) To: HIED-EMAILADMIN@LISTSERV.ND.EDU, windows-hied@lists.stanford.edu, office365@ucdavis.edu, imapext@ietf.org From: Andrew Laurence Date: Fri, 31 May 2013 22:18:42 +0000 (GMT) X-Mailer: iCloud Mail (1Q) X-Originating-IP: [128.195.168.36] Message-id: <26ee0ca4-2cfe-473b-9da2-c72faafd3873@me.com> Subject: [imapext] MS asks for feedback on standards support in Outlook/Exchange X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 May 2013 22:19:31 -0000 --Boundary_(ID_vN/NzFHg5hWwSvkg4zKs3w) Content-type: text/plain; charset=utf-8; format=flowed Content-transfer-encoding: quoted-printable Hello everyone, Forgive the massive list cross-posting, but I thought this noteworthy enou= gh to spread around.=EF=BB=BF Via their Openness@Microsoft blog, Microsoft invites input on their standa= rds support in Outlook and Exchange. I'm sure they'd like to hear thought= ful, detailed, insightful responses from the customer world at large. http://blogs.technet.com/b/openness/archive/2013/05/31/feedback-exchange-s= erver-and-outlook-standards.aspx Cheers, Andrew -- Andrew Laurence Office of Information Technology atlauren@uci.edu University of California, Irvine atlauren@me.com (Lists)= --Boundary_(ID_vN/NzFHg5hWwSvkg4zKs3w) Content-type: multipart/related; boundary="Boundary_(ID_Cz+sgrlnkvpGuyCDxujSPw)"; type="text/html" --Boundary_(ID_Cz+sgrlnkvpGuyCDxujSPw) Content-type: text/html; CHARSET=US-ASCII Content-transfer-encoding: 7BIT
Hello everyone,

Forgive the massive list cross-posting, but I thought this noteworthy enough to spread around.

Via their Openness@Microsoft blog, Microsoft invites input on their standards support in Outlook and Exchange.  I'm sure they'd like to hear thoughtful, detailed, insightful responses from the customer world at large.
http://blogs.technet.com/b/openness/archive/2013/05/31/feedback-exchange-server-and-outlook-standards.aspx

Cheers,
Andrew

 --
Andrew Laurence                Office of Information Technology
atlauren@uci.edu               University of California, Irvine
atlauren@me.com (Lists)

--Boundary_(ID_Cz+sgrlnkvpGuyCDxujSPw)-- --Boundary_(ID_vN/NzFHg5hWwSvkg4zKs3w)--