MBOX-Line: From alexey.melnikov at isode.com  Fri Feb  8 21:59:39 2013
To: imap-protocol@u.washington.edu
From: Alexey Melnikov <alexey.melnikov@isode.com>
Date: Fri Jun  8 12:34:50 2018
Subject: [Imap-protocol] Re: QRESYNC Questions
In-Reply-To: <20130208150507.Horde.lf3D8gdWBQ-bpWCXHv1Xug4@bigworm.curecanti.org>
References: <201302081451.r18EpC0d010777@mxout11.cac.washington.edu>
	<7237e649-33b3-47fb-a99a-4d3e7f28030f@flaska.net>
	<1360356725.26278.140661188781457.3532161E@webmail.messagingengine.com>
	<20130208150507.Horde.lf3D8gdWBQ-bpWCXHv1Xug4@bigworm.curecanti.org>
Message-ID: <98EEF27C-6BFB-47BB-B9E1-82CF7EB41428@isode.com>

On 8 Feb 2013, at 22:05, Michael M Slusarz <slusarz@curecanti.org> wrote:

> Quoting Bron Gondwana <brong@fastmail.fm>:
> 
>> On Sat, Feb 9, 2013, at 02:06 AM, Jan Kundr?t wrote:
>>> On Friday, 8 February 2013 15:50:38 CEST, Pete Maclean wrote:
>>> > When a client has not enabled CONDSTORE and sends an ENABLE
>>> > QRESYNC command to a server that advertises QRESYNC capability,
>>> > should the untagged response say "* ENABLED QRESYNC" or "*
>>> > ENABLED QRESYNC CONDSTORE"?  My reading of the spec tells me the
>>> > latter but I observe that another server sends the former.
>>> 
>>> I believe that both of these are compliant. I haven't found a definitive answer on this in either 5161 (ENABLE) or 5162 (QRESYNC) RFCs.
>> 
>> Cyrus does the latter. I also agree it is the correct way.
> 
> From a client's POV, it shouldn't matter.  

Right.

> It is crystal clear in the RFC that QRESYNC implies CONDSTORE, so the second QRESYNC is seen in an ENABLED response a client should automatically add CONDSTORE to the current capability list.

Exactly.

> But the better-safe-than-sorry approach is to include both since it would workaround potentially broken clients and nobody is going to fret over the additional 10 bytes anyway.

