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

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