59 lines
2.4 KiB
Plaintext
59 lines
2.4 KiB
Plaintext
MBOX-Line: From slusarz at curecanti.org Tue Dec 11 12:36:59 2012
|
|
To: imap-protocol@u.washington.edu
|
|
From: Michael M Slusarz <slusarz@curecanti.org>
|
|
Date: Fri Jun 8 12:34:49 2018
|
|
Subject: [Imap-protocol] BINARY for broken MIME parts
|
|
In-Reply-To: <CABa8R6tJV4iOjgckqLzEqLcdifRnVj6+g_7cB1vNd3YTgSt4pw@mail.gmail.com>
|
|
References: <CDD9BF88-A87D-41CB-A668-E2A7FE5CFE20@iki.fi>
|
|
<50C0A8F4.4070405@isode.com>
|
|
<809DCB83-1507-4F6B-8B70-D86042569C46@iki.fi>
|
|
<CABa8R6tJV4iOjgckqLzEqLcdifRnVj6+g_7cB1vNd3YTgSt4pw@mail.gmail.com>
|
|
Message-ID: <20121211133659.Horde.l5mdoRCy0RtyMMLrnOij-Q1@bigworm.curecanti.org>
|
|
|
|
Quoting Brandon Long <blong@google.com>:
|
|
|
|
> On Mon, Dec 10, 2012 at 9:56 PM, Timo Sirainen <tss@iki.fi> wrote:
|
|
>
|
|
>> a FETCH 1 BINARY[1]
|
|
>> * 1 FETCH (BINARY[1] NIL)
|
|
>> a OK [UNKNOWN-CTE] Invalid input?
|
|
|
|
As a client author, I would rather see this return with a NO tagged
|
|
response. This indicates that there is something wrong with the part
|
|
and the user can be notified that the part is unavailable ("this part
|
|
is broken! have sender re-send the message(?)") or, alternatively, the
|
|
UI can hide the part. In the above example, our client would simply
|
|
disregard the UNKNOWN-CTE as irrelevant.
|
|
|
|
>> I don't know how clients currently handle UNKNOWN-CTE. Maybe some would
|
|
>> think that if it's returned then the server can never decode that
|
|
>> content-transfer-encoding?..
|
|
>
|
|
> I would think [PARSE] would be more appropriate than UNKNOWN-CTE. Or just
|
|
> stick with [ALERT].
|
|
|
|
Agree with others that ALERT doesn't make sense. My interpretation of
|
|
ALERT is that its contents are independent of command interaction,
|
|
especially since there is no temporal requirement that alerts are
|
|
displayed when they are received.
|
|
|
|
Not sure if UNKNOWN-CTE is correct either since: in the example given,
|
|
it's a known CTE that the server can handle. It is bad message data
|
|
instead.
|
|
|
|
Although for that matter, PARSE doesn't seem to work either since it
|
|
is defined as an inability to parse the (MIME) headers of a section.
|
|
In this example, the headers are fine - it's the body that is broken.
|
|
|
|
I would throw out CORRUPTION as a possibility.
|
|
|
|
> Also, what if there is more than one message requested? We usually just
|
|
> fail to return the broken message and respond NO to the whole fetch, but
|
|
> return all the non-broken messages.
|
|
|
|
See above. I would agree that this is probably the best solution.
|
|
|
|
michael
|
|
|
|
|