Re: MIME part specifiers
On Thu, 29 Jan 2004, Paul Jarc wrote: Lastly (I hope), exactly which content-types must a server delve into? multipart/mixed, multipart/alternative, message/rfc822, ... message/delivery-status? multipart/digest? Others? Did you read RFC 3501? The answer is to be found on page 55. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum.
Re: MIME part specifiers
I wrote: Consider a top-level message/rfc822, which contains a message/rfc822 part, which contains a multipart/mixed part, which contains a text/plain part. I just checked the public Cyrus test server at cyrus.andrew.cmu.edu with such a message. (Well, the multipart part contained two text/plain parts instead of just one - close enough.) That server agrees with what Mark says ([1.1.HEADER] is the header of the multipart/mixed message), but it seems to disagree with the example in RFC3501. In my test message: [1] is an entire message/rfc822 message (itself encapsulated within a top-level message/rfc822 message), [1.TEXT] is the entire encapsulated multipart/mixed message, [1.1]is the same as [1.TEXT], and [1.1.1] is the first part contained in the multipart/mixed message. But in the RFC3501 example: [4.2] is an entire message/rfc822 part (contained within a multipart/mixed part), which is the header and body of a multipart/mixed message, [4.2.TEXT] is the body of [4.2] (a multipart/mixed body, without its header), and [4.2.1]is the first part contained within the multipart/mixed message. However, if I use a different test message with the same structure as the example in the RFC, then Cyrus agrees with the RFC example about the section specifiers. So how does this work, exactly? If [x] is a message/rfc822 part (where x is a section-part in the RFC3501 grammar), and the encapsulated message is not a multipart message, then it seems that [x.1] is the same as [x.TEXT] (according to my test with Cyrus, where x=1) - this mirrors the situation with a top-level message, so I guess that makes sense. But if the encapsulated message is multipart, then [x.1] is the first part of the multipart message (according to the RFC example, where x=4.2), unless [x] is itself encapsulated in a higher-level message/rfc822 message, in which case [x.1] is the entire body of the multipart message (according to my test with Cyrus, where x=1). Is this right? It seems unnecessarily complicated. Is Cyrus faulty? Are there other public testing servers available, running other server programs? paul
Re: MIME part specifiers
On Tue, 27 Jan 2004, Paul Jarc wrote: Consider a top-level message/rfc822, which contains a message/rfc822 part, which contains a multipart/mixed part, which contains a text/plain part. I just checked the public Cyrus test server at cyrus.andrew.cmu.edu with such a message. (Well, the multipart part contained two text/plain parts instead of just one - close enough.) That server agrees with what Mark says ([1.1.HEADER] is the header of the multipart/mixed message), but it seems to disagree with the example in RFC3501. In my test message: [1] is an entire message/rfc822 message (itself encapsulated within a top-level message/rfc822 message), [1.TEXT] is the entire encapsulated multipart/mixed message, [1.1]is the same as [1.TEXT], and [1.1.1] is the first part contained in the multipart/mixed message. I find that difficult to believe. 1.1 should be the first part contained in the multipart/mixed content. I'd like to see the exact text of the message that you claim works that way. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum.
Re: MIME part specifiers
Mark Crispin [EMAIL PROTECTED] wrote: On Tue, 27 Jan 2004, Paul Jarc wrote: That server agrees with what Mark says ([1.1.HEADER] is the header of the multipart/mixed message), but it seems to disagree with the example in RFC3501. In my test message: [1] is an entire message/rfc822 message (itself encapsulated within a top-level message/rfc822 message), [1.TEXT] is the entire encapsulated multipart/mixed message, [1.1]is the same as [1.TEXT], and [1.1.1] is the first part contained in the multipart/mixed message. I find that difficult to believe. 1.1 should be the first part contained in the multipart/mixed content. So you're saying that in this case, [1.1.HEADER] is not supposed to be a component of [1.1]? I'd like to see the exact text of the message that you claim works that way. It's still available on the server right now. telnet cyrus.andrew.cmu.edu imap 1 login anonymous your-email-address 2 select inbox 3 fetch 5 body[] 4 fetch 5 body[1.text] 5 fetch 5 body[1.1] paul
Re: MIME part specifiers
You misrepresented the structure of the message; there is a layer of encapsulation that you didn't mention. That's the cause of your confusion. The structure of that message is: MESSAGE/RFC822 (message id [EMAIL PROTECTED]) 1 MESSAGE/RFC822 (message id [EMAIL PROTECTED]) 1.1 MESSAGE/RFC822 (message id [EMAIL PROTECTED]) MULTIPART/MIXED 1.1.1 TEXT/PLAIN;NAME=test1.txt 1.1.2 TEXT/PLAIN;NAME=test2.txt That is, there is a multipart message, encapsulated within a single part message, encapsulated within a single part message. [] entire [EMAIL PROTECTED] [HEADER] header of [EMAIL PROTECTED] [TEXT] text of [EMAIL PROTECTED] (single part) [1] entire [EMAIL PROTECTED], same as [TEXT] [1.HEADER] header of [EMAIL PROTECTED] [1.TEXT] text of [EMAIL PROTECTED] (single part) [1.1] entire [EMAIL PROTECTED], same as [1.TEXT] [1.1.HEADER] header of [EMAIL PROTECTED] [1.1.TEXT] text of [EMAIL PROTECTED] (multipart) [1.1.1] test1.txt part of [EMAIL PROTECTED] [1.1.2] test2.txt part of [EMAIL PROTECTED] Now, let's suppose that the first part of [EMAIL PROTECTED] was itself a (nested) multipart with two parts, that is: MESSAGE/RFC822 (message id [EMAIL PROTECTED]) 1 MESSAGE/RFC822 (message id [EMAIL PROTECTED]) 1.1 MESSAGE/RFC822 (message id [EMAIL PROTECTED]) MULTIPART/MIXED MULTIPART/MIXED 1.1.1.1 TEXT/PLAIN;NAME=testa.txt 1.1.1.2 TEXT/PLAIN;NAME=testb.txt 1.1.2 TEXT/PLAIN;NAME=test2.txt We would then have: [] entire [EMAIL PROTECTED] [HEADER] header of [EMAIL PROTECTED] [TEXT] text of [EMAIL PROTECTED] (single part) [1] entire [EMAIL PROTECTED], same as [TEXT] [1.HEADER] header of [EMAIL PROTECTED] [1.TEXT] text of [EMAIL PROTECTED] (single part) [1.1] entire [EMAIL PROTECTED], same as [1.TEXT] [1.1.HEADER] header of [EMAIL PROTECTED] [1.1.TEXT] text of [EMAIL PROTECTED] (multipart) [1.1.1] first part of [EMAIL PROTECTED] (multipart) [1.1.1.1] testa.txt part of nested multipart [1.1.1.2] testb.txt part of nested multipart [1.1.2] test2.txt part of [EMAIL PROTECTED] -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum.
Re: MIME part specifiers
On Tue, 27 Jan 2004, Paul Jarc wrote: Now if there is a text/plain message encapsulated in a message/rfc822 (single part) message, so that [1] is the same as [TEXT], then is [1.MIME] the same as [HEADER]? Or is [x.MIME] only meaningful for parts of a multipart message? x.MIME is only meaningful for parts of a multipart message and never refers to HEADER part. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum.
Re: MIME part specifiers
Mark Crispin [EMAIL PROTECTED] wrote: x.MIME is only meaningful for parts of a multipart message and never refers to HEADER part. Ok. Cyrus seems to allow it, but I guess that won't hurt any correct clients. paul
Re: MIME part specifiers
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). BODY[] refers to the full message. BODY[1.TEXT] is meaningless since the first part isn't MESSAGE/RFC822. 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. while BODY[1] refers to the encapsulated message/rfc822 part *without* the surrounding MIME boundaries or extra header Correct. and BODY[1.TEXT] refers to only the body of the inner message/rfc822 part Yes, it refers to what would be the RFC822.TEXT of the encapsulated message, disregarding any MIME structure inside that message. Given a message with the following MIME structure, are these part specifier comments correct? Someone else is going to have to check that for you. I suggest that you take a message and feed it to a known working IMAP server (such as UW imapd), and do some experiments with various body parts until you understand how it works. An excellent playpen is the MIME torture test message on ftp://ftp.cac.washington.edu/mail/mime/torture-test.mbox -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum.
Re: MIME part specifiers
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
Re: MIME part specifiers
On Thu, 15 Jan 2004, Paul Jarc wrote: 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. Yes. 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]. 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. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum.
Re: MIME part specifiers
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
