[Python-Dev] Completing the email6 API changes.

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


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

        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.

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

More information about the Python-Dev mailing list