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

Dave Cridland <dave@cridland.net> writes:
>On Thu May 19 08:49:18 2005, Arnt Gulbrandsen wrote:
>> In RFC 3516, the one problem I ran into was the meaning of 
>> BINARY.SIZE for bodyparts that don't have an encoding, i.e. 
>> Content-Type: multipary/*, message/rfc822 or message/external.
>> 
>> Any opinions about the right BINARY.SIZE for such things?
>
>I have two:
>
>1) The size of the decoded part.
>
>Given that there *is* an encoding for multipart/* etc - it's mandated 
>to always be 7bit, which being the default, doesn't need to be 
>specified - then the same algorithm applies, and effectively reduces 
>to the same as BODY.SIZE would be if it existed.

Right.  Well, almost: multipart/* types and some message subtypes may
use 8bit or binary.  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.


Philip Guenther

