--On Monday, August 11, 2003 1:33 PM -0400 Pete Maclean <[EMAIL PROTECTED]> wrote:
FETCH 1:* BINARY[1]
I expect it would be rare for a client to issue a FETCH for a specified body part for multiple messages but it is certainly possible and I can imagine odd situations where it would be quite plausible.
If the client already knows that all the messages in the range are encoded
using only base64 or qp (the mandatory-to-implement encodings) then it knows
that the request "cannot" fail due to UNKNOWN-CTE, thus it's perfectly
reasonable for the client to issue that command.
Suppose that the server works through the messages, decoding each appropriate MIME part and sending it. Then suppose it hits one message that has the part encoded using a method that the server does not know about and cannot decode. The prescribed action is to send a NO response containing UNKNOWN-CTE. The problem lies in dealing with the requirement that the FETCH (like any IMAP command) totally succeed or totally fail. What should a server do?
I would have the server return all the decodeable parts, and return a NO
[UNKNOWN-CTE]. From that the client should be able to figure out what's going
on and act appropriately.
The second issue is what should a server do if it comes across a MIME part that it is asked to send as BINARY but which it cannot decode because the part is improperly encoded? Maybe there should be some response similar to UNKNOWN-CTE for this case?
I would just return UNKNOWN-CTE, since that's exactly what you're faced with.
--lyndon
