MBOX-Line: From guenther+imap at sendmail.com  Fri Aug 17 17:13:53 2012
To: imap-protocol@u.washington.edu
From: Philip Guenther <guenther+imap@sendmail.com>
Date: Fri Jun  8 12:34:48 2018
Subject: [Imap-protocol] IMAP part numbering corner case
In-Reply-To: <16C2B175-8815-42C5-B4BF-621EE86B8050@iki.fi>
References: <502DBEA4.2070204@verizon.net>
	<alpine.BSO.2.00.1208162109520.13998@morgaine.smi.sendmail.com>
	<060A31A9-066E-43F0-97AF-4B68522832B1@iki.fi>
	<alpine.BSO.2.00.1208162143500.13998@morgaine.smi.sendmail.com>
	<F673FF00-66E4-4C44-8E3D-5914E92F5083@iki.fi>
	<alpine.BSO.2.00.1208162213560.13998@morgaine.smi.sendmail.com>
	<16C2B175-8815-42C5-B4BF-621EE86B8050@iki.fi>
Message-ID: <alpine.BSO.2.00.1208170928570.22276@morgaine.smi.sendmail.com>

On Fri, 17 Aug 2012, Timo Sirainen wrote:
> On 17.8.2012, at 8.16, Philip Guenther wrote:
> > On Fri, 17 Aug 2012, Timo Sirainen wrote:
> > ...
> >> Anyway, [1.MIME] isn't a valid request in Joshua's test mail. 
> > 
> > Chapter and verse, please?
> > 
> > (There are specific restrictions on when HEADER and TEXT are valid, 
> > but no such restrictions are specified for the MIME part specifier...)
> 
> Well, I'm not sure if it's really a BAD-type of invalid, but [x.MIME] 
> refers to the part's MIME headers, and if the parent isn't a multipart, 
> there are no MIME headers, so the proper result is empty.

Well, RFC 3501 says:
         The MIME part specifier refers to the [MIME-IMB] header for
         this part.

[MIME-IMB] is a reference to RFC 2045.  That RFC doesn't define "header" 
itself, but does describe headers on not just body parts but entities:

2.4.  Entity
...
   <...>  Any sort of field may be present in the header of an entity,
   but only those fields whose names begin with "content-" actually have
   any MIME-related meaning.  Note that this does NOT imply thay they
   have no meaning at all -- an entity that is also a message has non-
   MIME header fields whose meanings are defined by RFC 822.

That implies to me that "header" doesn't necessarily mean "header on body 
part".

Also, RFC 3501 refers to [MIME-IMB] header fields in the description of 
the BODYSTRUCTURE fetch item, wherein message/rfc822 parts do have their 
header parsed to fill in the various fields.


So, I would argue that RFC 3501 does specify that .MIME work on all parts 
and, in the particular case of message/rfc822 part, is equivalent to 
asking for HEADER one level higher.


Philip Guenther


(In case that last "one level higher" doesn't make sense, here's a longer 
example:

------------------------------------------------------
Date: Fri, 01 Jan 2010 12:00 -0500
To: x@x.x
From: y@y.y
Subject: download on demand problem
MIME-Version: 1.0
Content-Type: message/rfc822

Date: Fri, 01 Jan 2012 12:00 -0500
To: y@y.y
From: x@x.x
Subject: Blast from the future
MIME-Version:1.0
Content-Type: multipart/mixed; boundary=foo

--foo

Do you know what to do when you see this message?

--foo
Content-Type: text/html

<HTML><BODY>Blah blah blah</BODY></HTML>
--foo
Content-Type: multipart/digest; boundary=bar

--bar

Subject: blah
Foo: bar

sdlfkj
sdlfkj
sdlfkj

--bar--

--foo--
------------------------------------------------------

In that, [1.3.1] is the digest message, starting at the "Subject: blah" 
line and continuing through the three "sdlfkj" lines.  [1.3.1.1] is just 
the three "sdlfkj" lines.  [1.3.1.1.MIME] is the same as [1.3.1.HEADER], 
which is the header of the digest message, being "Subject: blah", "Foo: 
bar", and the blank line after.)

