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

R. David Murray rdmurray at bitdance.com
Mon Sep 2 23:40:55 CEST 2013

On Mon, 02 Sep 2013 16:06:53 +0900, "Stephen J. Turnbull" <stephen at xemacs.org> wrote:

>>>>> Glenn writes: > >>>>> Steve writes:

>> OTOH, if the message is structured >> >> multipart/related >> multipart/alternative >> text/plain >> text/html >> image/png >> image/png >> >> the receiver can infer that the images are related to both text/* >> parts and DTRT for each. >With the images being treated as attachments. Or is there a syntax to >allow the text/html to embed the images and the text/plain to see them >as attachments? I believe the above is that syntax. But the standard doesn't say anything about this. The standard for multipart/alternative is RFC 2046, which doesn't know about multipart/related. RFC 2387 doesn't update RFC 2046, so it doesn't say anything about multipart/alternative within multipart/related, either. >I think the text/html wants to refer to things within its containing >multipart/related, but am not sure if that allows the intervening >multipart/alternative. I don't see why not. But it would depend on the implementations, which we'll have to test before recommending the structure I (theoretically :-) prefer.e

I'm still not understanding how the text/plain part refers to the related parts. 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.

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? I'm not aware of any, but you have much more experience with this stuff than I do. (Even text/enriched (RFC 1896) doesn't seem to have one, though of course there could be "extensions" that define both that and the font support you used as an example.)

--David

More information about the Python-Dev mailing list