Re: draft-nerenberg-imap-binary-00.txt

Issues with the binary extension:

(1) I concur with Mark's comments about syntax.  The current proposed 
syntax is unacceptable, the XFETCH strawman seems workable (with associated 
XFETCH response).  I could also deal with a fetch-item modifier as an 
alternative to a new command:
	C: A002 FETCH 1:5 <BINARY>BODY[1]
	S: * 1 FETCH (<BINARY>BODY[1] {#}...)
or
	C: A002 FETCH 1:5 <CHARSET=UTF8><BINARY>BODY[1]
        S: * 1 FETCH (<CHARSET=UTF8><BINARY>BODY[1] {#}...)
With that syntax, each modifier would have to describe how it interacts 
with various fetch items, for example, <BINARY>SIZE would return the size 
after removal of base64/QP encoding.

(2) I am currently opposed to a distinguished syntax for binary literals on 
the grounds that it introduces two silly states: a binary literal with 
non-binary content and a non-binary literal with binary content.  (In 
unextended IMAP, the latter is simply a protocol violation which robust 
implementations should detect.)  I would much prefer the statement that if 
the server advertises XFETCH BINARY, then the prohibition on the client 
sending binary literals for message content is lifted, and if the client 
issues the XFETCH command with BINARY option, then the prohibition on the 
server sending binary message content is lifted.

(3) If the concensus is against me on point 2, then I object to using a 
suffix to indicate a binary literal on the grounds that it breaks existing 
LITERAL+ detectors.  That objection would not apply to a prefix character.

(4) If a server advertises XFETCH BINARY, that should permit the use of 
binary CTE and binary literal content in APPEND.

(5) An unextended IMAP server is required to convert a body part with a 
binary CTE to base64.  An IMAP message store could receive a binary body 
part via the binary SMTP extension or an APPEND command (it is currently 
illegal protocol to have a true binary CTE in an APPEND).  If we ever want 
to support binary body parts signed by PGP or S/MIME, then we need a way to 
distinguish the canonical CTE from the requested/supplied CTE.  I don't 
have a strong opinion one way or the other, but the issue needs to be 
considered.

(6) BINARY and CHARSET=UTF8 conversions are no brainers (since an IMAP 
server with a halfway decent SEARCH command already implements them 
internally).  But the CHANNEL model is both very important for conversions 
not likely to be built into an IMAP server and rather tricky to get right 
due to security/firewall issues.

(7) I suggest we have an XFETCH (MD5) modifier, which computes the MD5 hash 
of the specified fetch BODY item -- MD5 is just a content conversion which 
happens to have a fixed size output.  May make channel security issues 
simpler, and could permit verification of PGP or S/MIME signatures without 
fetching all parts.

Note that I believe the CHANNEL mechanism in combination with an extension 
to the SMTP-SUBMIT protocol is the correct way to provide the ability to 
forward/resend an attachment without downloading it.

		- Chris