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

Quoting Brandon Long <[email protected]>:

> 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.

The problem with ALERT is that the contents must ALWAYS be shown to  
the user.  There are all sorts of IMAP commands where error responses  
can (and should) be handled without the user knowing about it.

Imagine that a user opens a mailbox and the client begins to download  
messages in the background.  When it reaches the message with bad  
binary data, and the server throws an ALERT, this ALERT (e.g. "Bad  
message data") will be displayed while the user is likely still in  
mailbox-level view.  It is sure to elicit a "WTF?" given that the  
alert has no context to the activity the user is performing.

> 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?

I definitely agree that, when the bad part is attempted to be  
displayed to the user, there should be some sort of error message  
displayed.  But the contents and timing of the error message should be  
the client's responsibility.  The server's job is to provide  
sufficient error code information so that the client can accurately  
and clearly explain to the user the problem.

> And that's on top of the fact that the client doesn't even
> know which message was broken.

We send body requests for each part separately for precisely this  
reason.  Slightly less efficient but necessary for correct error  
handling.  It's the same sort of error reporting vs. efficiency  
tradeoff as not using LITERAL+ when doing a MULTIAPPEND.

> 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.

I'll agree that as written (especially in the example), CORRUPTION  
seems to address the issue of something wrong from a server  
metadata/infrastructure POV rather than an issue with the contents of  
the message.  In the absence of an explicit BROKEN response code, we  
are probably trying to fit a square peg into a triangular hole.

michael

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