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
-----------------------------------------------------------------
- Re: Issues with the BINARY extension Pete Maclean
- Re: Issues with the BINARY extension Steve Hole
- Re: Issues with the BINARY extension Lyndon Nerenberg
- Re: Issues with the BINARY extension Lyndon Nerenberg
- Re: Issues with the BINARY extension Pete Maclean
- Re: Issues with the BINARY extension Ken Murchison
- Re: Issues with the BINARY extensio... Timo Sirainen
- Re: Issues with the BINARY extension Mark Crispin
- Re: Issues with the BINARY extension Pete Maclean
- Re: Issues with the BINARY extension Lyndon Nerenberg {VE6BBM}
- Re: Issues with the BINARY extensio... Timo Sirainen