MBOX-Line: From dave at cridland.net  Thu May 19 06:34:59 2005
To: imap-protocol@u.washington.edu
From: Dave Cridland <dave@cridland.net>
Date: Fri Jun  8 12:34:36 2018
Subject: [Imap-protocol] BINARY.SIZE for a multipart 
In-Reply-To: <200505191237.j4JCbkjl020307@lab.smi.sendmail.com>
References: <7B822F730F822147977ED5B684ACE490241504@xmb-sjc-21b.amer.cisco.com> 
	<QfUp/SCMRFPLnvUgJnBShw.md5@prosecco.oryx.com> 
	<10845.1116494075.615509@peirce.gestalt.entity.net> 
	<200505191237.j4JCbkjl020307@lab.smi.sendmail.com>
Message-ID: <11305.1116509699.754530@peirce.gestalt.entity.net>

On Thu May 19 13:37:46 2005, Philip Guenther wrote:
> Right.  Well, almost: multipart/* types and some message subtypes 
> may
> use 8bit or binary.

Oh. Yes, you're quite right. Presumably, this would indicate the 
"maximal domain", as it were, of the subparts.

>   Still, the logic holds: treat them as you would any
> part with an identity encoding: make BINARY[section] return the 
> same as
> BODY[section] and make BINARY.SIZE[section] return the size of those
> items.

No, the logic fails with binary subparts - those need to be encoded 
by the IMAP server for RFC822.SIZE and BODY[section]. Hence my 
comment that the converse of (2) is probably true.

This is probably hypothetical, since as far as I know all 
implementations store RFC2822 messages without using binary encoding.

Dave.

