MBOX-Line: From tss at iki.fi  Fri Jun 22 10:57:25 2012
To: imap-protocol@u.washington.edu
From: Timo Sirainen <tss@iki.fi>
Date: Fri Jun  8 12:34:48 2018
Subject: [Imap-protocol] BINARY + NOTIFY
In-Reply-To: <4FE454E7.4080001@isode.com>
References: <1340151854.5967.57.camel@hurina> <4FE454E7.4080001@isode.com>
Message-ID: <06330C04-8714-43B6-B693-0493315B63B9@iki.fi>

On 22.6.2012, at 14.20, Alexey Melnikov wrote:

> On 20/06/2012 01:24, Timo Sirainen wrote:
>>>          If the server does not know how to decode the section's CTE, it
>>>          MUST fail the request and issue a "NO" response that contains
>>>          the "UNKNOWN-CTE" extended response code.
>> Looking at Cyrus code it appears to abort the FETCH immediately if this
>> situation happens and [UNKNOWN-CTE] is returned as tagged reply.
>> 
>> Now, what to do when NOTIFY's fetch-att list includes BINARY[part] and
>> it can't be decoded? Send an untagged NO [UNKNOWN-CTE] after the FETCH
>> reply? What if BINARY[part] is the only requested fetch-att and it can't
>> be fetched? The server can't send an empty FETCH reply.
> 
> Can you avoid sending the FETCH reply in such cases?

Yes, but would I still send * NO [UNKNOWN-CTE] ? :)


