[Python-Dev] Completing the email6 API changes. (original) (raw)

Stephen J. Turnbull stephen at xemacs.org
Tue Sep 3 03:56:36 CEST 2013

R. David Murray writes:

I'm still not understanding how the text/plain part refers to the related parts.

Like this: "Check out this picture of my dog!" Or this: "The terms of the contract are found in the attached PDF. Please print it and sign it, then return it by carrier pigeon (attached)." With this structure

multipart/alternative
    text/plain
    multipart/related
        text/html
        application/pdf
        application/rfc6214-transport

the rendering of the text/plain part will not show evidence of the PDF at all (eg, a view/download button), at least in some of the MUAs I've tested. And it should not, in an RFC-conforming MUA.

I can understand the structure Glen found in Applemail: a series of text/plain parts interspersed with image/jpg, with all parts after the first being marked 'Contentent-Disposition: inline'. Any MUA that can display text and images ought to handle that correctly and produce the expected result. But that isn't what your structure above would produce. If you did:

multipart/related
    multipart/alternative
        text/html
        text/plain
    image/png
    text/plain
    image/png
    text/plain

and only referred to the png parts in the text/html part and marked all the parts as 'inline' (even though that is irrelevant in the text/html related case), an MUA that knew about this technique could display it "correctly", but an MUA that is just following the standards most likely won't.

OK, I see that now. It requires non-MIME information about the treatment of the root entity by the implementation. On the other hand, it shouldn't hurt. RFC 2387 explicitly specifies that at least some parts of a contained multipart/related part should be able to refer to entities related via the containing multipart/related. Since it does not mention any restrictions on contained root entities, I take it that it implicitly specifies that any contained multipart may make such references. But I suspect it's not implemented by most MUAs. I'll have to test.

I don't see any way short of duplicating the image parts to make it likely that a typical MUA would display images for both a text/plain sequence and a text/html related part. On the other hand, my experience with MUAs is actually quite limited :)

Unless there is some standard for referring to related parts in a text/plain part?

No, the whole point is that we MUA implementers know that there is no machine-parsable way to refer to the related parts in text/plain, and therefore the only way to communicate even the presence of the attachment in

multipart/related
    text/plain
    image/jpeg; name="dog-photo.jpg"

to the receiving user is to make an exception in the implementation and treat it as multipart/mixed.[1]

It does make sense, i.e., doesn't require any information not already available to the implementation.

I wonder if use of external bodies could avoid the duplication in current implementations. Probably too fragile, though.

Footnotes: [1] This is conformant to the RFC, as the mechanism of "relation" is explicitly application-dependent.

More information about the Python-Dev mailing list