mailing list archives

meli community discussions

⚠️ if something does not work as intended when interracting with the mailing lists,
reach out Github mirror Gitea repo @epilys:matrix.org

[Imap-protocol] BINARY + NOTIFY

E-mail headers
From: Timo Sirainen <tss@iki.fi>
To: imap-protocol@u.washington.edu
Date: Fri, 08 Jun 2018 12:34:48 -0000
Message-ID: 1340151854.5967.57.camel@hurina permalink / raw / eml / mbox 
>          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.
Reply
E-mail headers
From: alexey.melnikov@isode.com
To: imap-protocol@localhost
Date: Fri, 08 Jun 2018 12:34:48 -0000
Message-ID: 4FE454E7.4080001@isode.com permalink / raw / eml / mbox 
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?
Reply
E-mail headers
From: tss@iki.fi
To: imap-protocol@localhost
Date: Fri, 08 Jun 2018 12:34:48 -0000
Message-ID: 06330C04-8714-43B6-B693-0493315B63B9@iki.fi permalink / raw / eml / mbox 
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] ? :)
Reply
E-mail headers
From: alexey.melnikov@isode.com
To: imap-protocol@localhost
Date: Fri, 08 Jun 2018 12:34:48 -0000
Message-ID: 4FE4C29F.7090200@isode.com permalink / raw / eml / mbox 
On 22/06/2012 18:57, Timo Sirainen wrote:
> 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] ? :)

Sure, why not? (Although too bad it doesn't tell which messages caused 
UNKNOWN-CTE...)
Reply