Re: client support for RFC 3516 (BINARY)?

On Fri, Dec 5, 2014 at 2:42 PM, Dave Cridland <[email protected]> wrote:
>
> I have a vague recollection that it's in Inky, http://inky.com/ - it's
> something of a no brainer to support in a client, in any case. Servers have
> to handle binary append, such is somewhat harder.
>

My reading of binary append is just that the server needs to accept the
<literal8> syntax and accept data that contains NULs. The spec allows for
modifying the CTE at append time, but discourages it in section 6 ("this
should only be done when it is absolutely necessary"). So it seems like
supporting binary append should be fairly straightforward.

Are you perhaps referring to the re-encoding of binary data with a
conforming CTE when it is FETCHed with a (non-binary) BODY or
BODYSTRUCTURE? This requirement puzzles me because it seems to be
retroactive, and independent of whether BINARY append is supported. We
already have binary data in our system, and we make no attempt to re-encode
it for IMAP download now, even without implementing BINARY. Is the spec
assuming that, prior to implementing BINARY, there was no way for binary
data to get into the system, and so only a server that supports BINARY
append needs to worry about re-encoding it for download?

_______________________________________________
imapext mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/imapext