[Python-Dev] Completing the email6 API changes.

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:


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.)


More information about the Python-Dev mailing list