101 lines
4.1 KiB
Plaintext
101 lines
4.1 KiB
Plaintext
MBOX-Line: From blong at google.com Tue Dec 11 12:47:59 2012
|
|
To: imap-protocol@u.washington.edu
|
|
From: Brandon Long <blong@google.com>
|
|
Date: Fri Jun 8 12:34:49 2018
|
|
Subject: [Imap-protocol] BINARY for broken MIME parts
|
|
In-Reply-To: <20121211133659.Horde.l5mdoRCy0RtyMMLrnOij-Q1@bigworm.curecanti.org>
|
|
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>
|
|
<20121211133659.Horde.l5mdoRCy0RtyMMLrnOij-Q1@bigworm.curecanti.org>
|
|
Message-ID: <CABa8R6t+ogP2XcUqqGVxcUAp-kk+dNwuyKftLKTFhUjkRR1wZQ@mail.gmail.com>
|
|
|
|
I'm confused about the consensus against ALERT.
|
|
|
|
This is an error condition that doesn't have a correct error code defined,
|
|
how is the client supposed to know what the error is to tell the user? The
|
|
server does know the exact error condition, however.
|
|
|
|
In general, I haven't understood the new error responses as "replacements"
|
|
for ALERT, as they're not backward compatible. A client which gets an
|
|
error response is doesn't understand does what, nothing? So if I change an
|
|
ALERT to a CANNOT, I'm just having clients which don't know CANNOT drop
|
|
information instead of helping the user.
|
|
|
|
I'm also not sure what the client is supposed to do in this situation
|
|
except display an error to the user. Do you expect the client to fall back
|
|
to a non-binary fetch and hope it has better luck with decoding than the
|
|
server did? And that's on top of the fact that the client doesn't even
|
|
know which message was broken.
|
|
|
|
Anyways, CORRUPTION to me implies errors accumulated in transport or
|
|
storage, which the user might attribute to the server, which is hardly the
|
|
case if the message was broken when the server acquired it.
|
|
|
|
Brandon
|
|
|
|
|
|
On Tue, Dec 11, 2012 at 12:36 PM, Michael M Slusarz
|
|
<slusarz@curecanti.org>wrote:
|
|
|
|
> 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
|
|
>
|
|
>
|
|
> ______________________________**_________________
|
|
> Imap-protocol mailing list
|
|
> Imap-protocol@u.washington.edu
|
|
> http://mailman2.u.washington.**edu/mailman/listinfo/imap-**protocol<http://mailman2.u.washington.edu/mailman/listinfo/imap-protocol>
|
|
>
|
|
-------------- next part --------------
|
|
An HTML attachment was scrubbed...
|
|
URL: <http://mailman13.u.washington.edu/pipermail/imap-protocol/attachments/20121211/ec3c4586/attachment.html>
|