Re: client support for RFC 3516 (BINARY)?

Quoting Dave Cridland <[email protected]>:

> On 5 Dec 2014 22:03, "Jamie Nicolson (倪志明)" <[email protected]> wrote:
>>
>> Anyone know of clients that support RFC 3516? It seems like it could be
> particularly useful for mobile clients, to reduce both download size and
> CPU usage for base64-decoding.
>>
>
> 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.

Horde/IMP uses binary, if available, to FETCH binary data.  As Dave  
mentions, this is trivial to do in a client (if BINARY FETCH data is  
available, you just skip all the code client-side that does the  
transfer-decoding).

Might as well add some additional notes here, as they may possible be  
of interest to future implementers...

Current (or at least recent-ish versions) servers do several different  
things when they encounter bad encoded data.  See, e.g.:

http://markmail.org/message/anldcux5fhqz6m65

Dovecot used to issue NIL ... newer versions still issue NIL but with  
a UNKNOWN-CTE response.  Cyrus does the best it can to decode and  
returns that data.

This can be seen as a limitation of the current BINARY spec, since it  
isn't obvious which (if any) of these responses are correct.  Speaking  
as a client author, I just care about the UNKNOWN-CTE response though  
since that leaves open the possibility of fetching the unencoded part  
and dealing with broken transfer-encoding the way that I want to.

BINARY APPENDs are a different story though.  It is broken on multiple  
servers, and in several different ways.  At a minimum, versions of  
UW-IMAP, Cyrus, and Sun Java System Messaging have problems.  IIRC,  
one of the issues is that these servers have issues with the literal8  
format.  It's so widespread that we've disabled LITERAL+ entirely when  
appending BINARY data in order to prevent unneeded traffic.  (We  
normally use LITERAL+ for small APPENDs as a compromise between the  
need to catch errors before sending the data - RFC 4549 - and the  
benefits of pipelining).

My thought originally was, if BINARY was available, then always APPEND  
using that because it prevents us from having to scan the output data  
on the client side to determine whether the data really was binary  
(null, long-lines) or not.  But the above described server issues  
encountered ended that experiment fairly quickly.

michael

___________________________________
Michael Slusarz [[email protected]]

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