[Python-Dev] Completing the email6 API changes.

[Stephen J. Turnbull]

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.