MBOX-Line: From lyndon at orthanc.ca  Sat Aug 11 08:43:32 2012
To: imap-protocol@u.washington.edu
From: Lyndon Nerenberg <lyndon@orthanc.ca>
Date: Fri Jun  8 12:34:48 2018
Subject: [Imap-protocol] BINARY + multiparts
In-Reply-To: <283BA59D-2B55-4E29-BD2F-D3C392D2E673@iki.fi>
References: <283BA59D-2B55-4E29-BD2F-D3C392D2E673@iki.fi>
Message-ID: <E7F9B601-2050-46A2-8A57-C945F3206026@orthanc.ca>


On 2012-08-10, at 19:39 PM, Timo Sirainen wrote:

> for a message that contains base64-encoded MIME parts. Do you change the MIME headers' Content-Transfer-Encoding value to "binary"? Or do you just return NO to the command? I implemented the former, but the RFC doesn't seem to require it.

If you convert the MIME part to binary encoding, you have to change the CTE header's value, else you have an invalid MIME object.

I was very uncomfortable about this sort of body content re-writing, and wanted to restrict binary fetch to terminal MIME body parts.  In fact, I had thought that's how I had written the spec ? shows you how long it's been since I read the RFC.  So either somebody talked me out of that restriction, or I just screwed up and forgot to include it in the document :-P

But given what's there today, "Fetch 1 Binary []" is a valid command in the fact of nested body content, so if it's not too hard to do the CTE rewrite, you might as well do it.  But I would strongly advise client authors to restrict binary fetches to terminal body parts, as the behaviour of fetching non-terminals is going to be unpredictable.

--lyndon

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 858 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://mailman13.u.washington.edu/pipermail/imap-protocol/attachments/20120811/caf029a7/attachment.sig>
