Re: [Extra] imap4rev2: RFC3516 BINARY

BINARYMIMEWe ran into some issues trying to implement BINARY, and also
didn't see a large number of clients which supported it (looking back, we
did this work mostly in 2014, so a while back).  My memory is a bit sketchy
of everything we ran into.

If I recall, we had some questions with the standard, ie what happens if
you request binary for non-leaf branches of the MIME tree (section-binary
implies that there's something special about what you can request, but it's
actually just the section-part).  Ie, if you ask for BINARY on a
message/rfc822, are we supposed to decode each individual part in that
multipart?  Again, we could have just responded NO with unknown-cte, I
guess.  There was also the question of what to do with data we'd munged, ie
we have heuristics for extracting base64 data when there are multiple
sections of it, or where a mailing list appended a non-encoded footer on
base64 data, etc, we probably would have just sent the data we'd extracted
instead of giving an unknown-cte response, for example.

We also had some issues with binary append which I don't recall, though
that you can just not support with some minor annoyance (why it didn't have
a separate CAPABILITY for APPEND instead of just allowing the server to say
NO, I dunno).  If I recall, we were worried about what version to store and
what to vend to non BINARY requests, and how that interoperated.  I guess
this wouldn't have mattered that much, we already have a "buggy" APPEND by
the standard, since the standard basically says you have to accept whatever
crap they APPEND, even if not an email message, and we have some base level
requirements for message formatting.

Overall, it was a part of our investigation into using binary more in
emali, ie cte binary and smtp (BDAT and BINARYMIME).  We implemented BDAT,
but our testing basically showed very few clients or servers that could
handle cte binary with embedded nulls.

Perhaps a cleaned up more strictly specified BINARY could be included,
otherwise I think you'll get a lot of unknown-cte responses from folks who
have to claim support but can't.
For one, its not clear that you can stream a base64 decode, at the least
you'd need to do two passes, one to verify correctness of the base64 data,
and the second to stream decode it.

Brandon

On Thu, Nov 8, 2018 at 3:34 AM Bron Gondwana <brong@fastmailteam.com> wrote:

> This is one of the open issues from imap4rev2 - which extensions should be
> part of the mandatory baseline.
>
> This one might need some clarification from Alexey - I'm not sure why it's
> not trivially obviously a good thing to include.  There was some stuff
> about "ability to fetch the decoded size" discussed, but I didn't capture
> good notes.
>
> Arguments for and against, or additional discussion, in response to this
> please.
>
> Cheers,
>
> Bron.
>
> --
>   Bron Gondwana, CEO, FastMail Pty Ltd
>   brong@fastmailteam.com
>
>
> _______________________________________________
> Extra mailing list
> Extra@ietf.org
> https://www.ietf.org/mailman/listinfo/extra
>