Mark Crispin <[EMAIL PROTECTED]> wrote: > On Thu, 15 Jan 2004, Paul Jarc wrote: >> Please confirm my understanding here. In a text/plain message, >> BODY[TEXT] and BODY[1.TEXT] refer to the same data (the message body), >> and BODY[] and BODY[1] refer to the same data (the full message, >> header and body). > > No. In a text/plain message, BODY[TEXT] and BODY[1] refer to the same > data (the message body).
Ok. I think that could stand to be clarified in a future update of RFC3501. >> But in a multipart/* message which contains a message/rfc822 part >> as its only part, BODY[TEXT] refers to the body of the outer >> multipart message > > BODY[TEXT] refers to the message body. It's the same as RFC822.TEXT, > disregarding any MIME structure. Ok, that's what I was saying. Now, IIUC, if the top-level message is message/rfc822, then [TEXT] is (the header and body of) the encapsulated message, [1] is the same, and [1.HEADER] and [1.TEXT] are the encapsulated header and body individually. 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. The doubly-encapsulated message has structure - a header and body - but that structure is not expressible in IMAP's part specifiers. Right? > An excellent playpen is the MIME torture test message on > ftp://ftp.cac.washington.edu/mail/mime/torture-test.mbox Thanks. 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]) paul
