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.
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
