Re: [Imap-protocol] BINARY for broken MIME parts

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
<[email protected]>wrote:

> Quoting Brandon Long <[email protected]>:
>
>  On Mon, Dec 10, 2012 at 9:56 PM, Timo Sirainen <[email protected]> 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
> [email protected]
> http://mailman2.u.washington.**edu/mailman/listinfo/imap-**protocol<http://mailman2.u.washington.edu/mailman/listinfo/imap-protocol>
>

_______________________________________________
Imap-protocol mailing list
[email protected]
http://mailman2.u.washington.edu/mailman/listinfo/imap-protocol