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.
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:  This is conformant to the RFC, as the mechanism of "relation" is explicitly application-dependent.