[Python-Dev] Completing the email6 API changes.

[R. David Murray]

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