Mark Crispin <[EMAIL PROTECTED]> wrote: > On Thu, 15 Jan 2004, Paul Jarc wrote: >> If the encapsulated message itself is also message/rfc822, then >> [1.TEXT] is the header and body of the doubly-encapsulated message, >> and there is no way to refer to the header and body individually. > > Wrong. > > The header of the doubly-encapsulated message is [1.1.HEADER] and the body > of the doubly-encapsulated message is [1.1.TEXT].
So then, is [1.1] also equivalent to [1.TEXT] in this case? The example in RFC3501, 6.4.5 suggests otherwise - in that message, [4.2] is a message/rfc822 part, but [4.2.TEXT] is not the same as [4.2.1]. Consider a top-level message/rfc822, which contains a message/rfc822 part, which contains a multipart/mixed part, which contains a text/plain part. The example in the RFC would suggest that since the singly-encapsulated message/rfc822 part, in its entirety, is [1], then the first component of the contained multipart/mixed part - i.e., the innermost text/plain part - should be [1.1], while [1.TEXT] consists of [1.1] plus the surrounding MIME stuff. ([4.2] from the example corresponds to [1] here.) So it seems to me one of these must be true: - The example in the RFC is incorrect, - IMAP cannot identify certain parts of certain MIME structures, or - Contrary to intuition, [x.HEADER] and [x.TEXT] do not necessarily refer to components of [x], and if [y] is message/rfc822, then the meaning of [y.1] depends on the content-type of the *encapsulated* message. >> Somewhat related: is a client allowed to request multiple BODY[...] >> parts in a single FETCH command? Does it come up in practice? E.g.: >> tag FETCH 1 (BODY[1.TEXT]<17.42> BODY[2.HEADER]<42.101> BODY[3.2.1]) > > Yes and yes. Yuck. Ok, thanks. paul
