MBOX-Line: From alexey.melnikov at isode.com  Fri Jun 22 04:20:07 2012
To: imap-protocol@u.washington.edu
From: Alexey Melnikov <alexey.melnikov@isode.com>
Date: Fri Jun  8 12:34:48 2018
Subject: [Imap-protocol] BINARY + NOTIFY
In-Reply-To: <1340151854.5967.57.camel@hurina>
References: <1340151854.5967.57.camel@hurina>
Message-ID: <4FE454E7.4080001@isode.com>

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?




