27 lines
1.1 KiB
Plaintext
27 lines
1.1 KiB
Plaintext
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?
|
|
|
|
|
|
|
|
|