Issues with the BINARY extension

[Pete Maclean]

I have been looking at implementing the BINARY extension (as per RFC 3516) 
in my server.  I was tempted because it seemed that it might be a good 
marketing item and because, at first glance, it looked very easy to 
do.  After some deeper thought however I have come to see two issues with 
handling FETCH BINARY commands that concern me.

The first concerns a situation that might never happen but which, it seems, 
a server must be prepared for.  Suppose a client sends a command such as:

	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.  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?  Abort 
the command at this point and send a tagged NO response?  Carry on to the 
end and send a tagged NO response?  Send an untagged NO response?  Avoid 
the contingency by going through all the messages twice, once to verify 
that it can decode each and then once more to send each one?

A related issue is that I feel the need for some clarification on the whole 
business of commands completely succeeding or completely failing.  I have 
come to regard this as an important dictum for IMAP implementation as it 
has been mentioned a few times on this list.  (For example, in a message 
from April 2000, Mark stated "IMAP guarantees that commands succeed 
completely or fail completely.")  However I can find no statement to this 
effect in RFC 3501 and am not sure just what it means to fail or succeed 
completely?  Given that Mark has also made it clear that there is no 
problem with a command failing but still resulting in useful data being 
sent to the client, I have tentatively concluded that the rule pertains 
only to commands that change multiple and non-atomic things on the 
server.  Obvious contenders are APPEND, COPY, DELETE, EXPUNGE and STORE, 
plus instances of FETCH  that have the side effect of setting \Seen 
flags.  This last case makes a FETCH BINARY all the more awkward in that it 
is uniquely allowed to fail in the way discussed above.  I am left tempted 
to think that the only way out of the quandary I described in my first 
paragraph is the last option, that of going through all the messages 
twice.  Maybe that is just what has to be done but it is unappealing for 
two reasons.  First, it could result in a substantial delay before the 
first response data gets sent.  Second, it means implementing the double 
traversal to deal with a situation that might never happen.  This 
difficulty, however, seems in contradiction to a statement made by Lyndon 
Nerenberg in a message from this May: "I implemented Binary in the Cyrus 
server, and it was a very straight-forward modification."  Am I taking the 
completely-succeed-or-completely-fail requirement too seriously?

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?

My thanks for any input,

Pete Maclean 

--
-----------------------------------------------------------------
For information about this mailing list, and its archives, see: 
http://www.washington.edu/imap/imap-list.html
-----------------------------------------------------------------