Re: [lemonade] Regarding CONDSTORE IMAP extension

Dave Cridland <dave@cridland.net> Tue, 03 December 2013 05:52 UTC

Return-Path: <dave@cridland.net>
X-Original-To: lemonade@ietfa.amsl.com
Delivered-To: lemonade@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0EB3E1AE044 for <lemonade@ietfa.amsl.com>; Mon, 2 Dec 2013 21:52:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.378
X-Spam-Level:
X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 277TbVzun65S for <lemonade@ietfa.amsl.com>; Mon, 2 Dec 2013 21:52:30 -0800 (PST)
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 DEDA61AE038 for <lemonade@ietf.org>; Mon, 2 Dec 2013 21:52:29 -0800 (PST)
Received: by mail-ob0-f172.google.com with SMTP id gq1so14019858obb.31 for <lemonade@ietf.org>; Mon, 02 Dec 2013 21:52:27 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cridland.net; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ecy3z+g0NNQH5j60BomldG78DLvFQ1mNrepScun/zqU=; b=YIxJxTw2SVT146oUZrMjGhqDu1IGbyFa0UEgqbblTcd0GP45ASaEqwTIHd7KcadPzD RGPFmhZDFWu++jQoTzoRGKn2ePAqndKzI7KRBnxBWllvLT6NIg1fvrWE8n4+LHGpThrL AyOETOfH+aRUAGhHz3Ma33vtJVzB2nnCYEuEE=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=ecy3z+g0NNQH5j60BomldG78DLvFQ1mNrepScun/zqU=; b=gnbKCey+PtSAHhsPyrGOap/ezVg+elppVfSsocM8OPfoGobO/8cvQ54GCkAh8+51s9 GBnrOcV5bM0a8DR586V30NfdCcc6AzebfJ6QrWEF9vpOIDjyZb0qO201J5r/zeaVM8dB r75SVGWERhHmZ4eCEdCALVGyvcft9smY23UDdRdlNHoPdK6JUHkbAufG4ajzGjN+1kCU k2pqM8PHT6o6N9E1g4ae+q21MsGLmXmjmqFy5jznVoacYc0teXEowN/R7vVXqnCPPB0G O/QHIhdbPDz7UAfi8dC/xkdbfZFzSRhaSEQszLvmj3Gvacejdz2kJ5NNI5Y20jYg6YIH sF8g==
X-Gm-Message-State: ALoCoQnZUvE4wzz7JAhTPmBI+Cpg4vL+EtsWDv4nI89eoLDd+2W3g2VM4cbJD/HSlzliX5/EJq5B
MIME-Version: 1.0
X-Received: by 10.60.62.172 with SMTP id z12mr57703189oer.4.1386049947241; Mon, 02 Dec 2013 21:52:27 -0800 (PST)
Received: by 10.60.121.97 with HTTP; Mon, 2 Dec 2013 21:52:27 -0800 (PST)
In-Reply-To: <1386028949.42306.YahooMailNeo@web160201.mail.bf1.yahoo.com>
References: <1386021084.78345.YahooMailNeo@web160203.mail.bf1.yahoo.com> <9576257CC412C5B483A28644@96B2F16665FF96BAE59E9B90> <1386028949.42306.YahooMailNeo@web160201.mail.bf1.yahoo.com>
Date: Tue, 03 Dec 2013 05:52:27 +0000
Message-ID: <CAKHUCzzFq_FCf6CBOTFH-rPJg_z72dttP9nuRRx9VsTJtM1Zsg@mail.gmail.com>
From: Dave Cridland <dave@cridland.net>
To: Samsung SVL <samsungsvl@yahoo.com>
Content-Type: multipart/alternative; boundary="001a11c20976bf21e004ec9ae6f3"
Cc: "lemonade@ietf.org" <lemonade@ietf.org>, Chris Newman <chris.newman@oracle.com>
Subject: Re: [lemonade] Regarding CONDSTORE IMAP extension
X-BeenThere: lemonade@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Enhancements to Internet email to support diverse service enivronments <lemonade.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/lemonade>, <mailto:lemonade-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/lemonade/>
List-Post: <mailto:lemonade@ietf.org>
List-Help: <mailto:lemonade-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/lemonade>, <mailto:lemonade-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 03 Dec 2013 05:52:32 -0000

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

https://ietf.org/doc/draft-ietf-qresync-rfc5162bis/

If you think this needs to be clearer in the new document, please let the
document authors, and the mailing list at imapext@ietf.org know.


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

> Hi Chris,
>
> Thanks for your clarification.
>
> Regards,
> Jay
>
>   ------------------------------
>  *From:* Chris Newman <chris.newman@oracle.com>
> *To:* Samsung SVL <samsungsvl@yahoo.com>; lemonade@ietf.org
> *Sent:* Monday, 2 December 2013, 18:10
>
> *Subject:* Re: [lemonade] Regarding CONDSTORE IMAP extension
>
> --On December 2, 2013 13:51:24 -0800 Samsung SVL <samsungsvl@yahoo.com>
>
> wrote:
>
> > Hi All,
> >
> > Kindly clarify my below query regarding "CONDSTORE" IMAP Extension.
> >
> > When IMAP server advertises the "CONDSTORE" support as part of
> > CAPABILITIES, client assumes that server support IMAP CONSTORE
> > extension.
> >
> > As per RFC 4551,  client issues SELECT command  for a mailbox in the
> > below format and receives the response with HIGHESTMODSEQ value as  "1"
> >
> > C: A142 SELECT INBOX
> >
> > During the subsequent SELECT command, client receives "HIGHESTMODSEQ"
> > value always set to "1". Its not getting incremented with respect to the
> > changes in the mailbox.
> >
> > Some IMAP server changes the HIGHESTMODSEQ value only when client issues
> > SELECT command in the below format.
> >
> > C:A142 SELECT "INBOX" (QRESYNC ("UIDVALIDITY" "HIGHESTMODSEQ"))
> >
> > Kindly clarify which format is right one, because most of the IMAP server
> > behaves differently.
>
>
> Technically, the former command is correct only if you've previously
> issued
> a condstore-enabling command (or don't want to use condstore) and the
> latter is correct only if the server advertises QRESYNC and you have
> issued
> "ENABLE QRESYNC" previously. For more details see RFC 4551 and RFC 5162.
>
> Have you tried using:
>
> C: A142 SELECT INBOX (CONDSTORE)
>
> That's a condstore-enabling command that servers advertising the CONDSTORE
> capability are required to support. Servers are free to not return
> HIGHESTMODSEQ at all until a condstore-enabling command occurs, and then
> they MUST return either HIGHESTMODSEQ or NOMODSEQ.
>
> Of course, if a server is returning HIGHESTMODSEQ and not updating it
> after
> flag changes, that server may have a bug, so you may have to fallback to
> not using CONDSTORE with that server and just do a full resync every time.
> You might want to report that bug to the server vendor so they have the
> opportunity to fix it in a subsequent release.
>
>         - Chris
>
>
>
>
> _______________________________________________
> lemonade mailing list
> lemonade@ietf.org
> https://www.ietf.org/mailman/listinfo/lemonade
> Supplemental Web Site:
> http://www.standardstrack.com/ietf/lemonade
>