Re: multipart/alternative question
* On 16 Jul 2009, Kyle Wheeler wrote:
> >
> > Multipart/alternative containers are specifically excluded from ever
> > being traversed. Why? Because mutt at this stage has no way of knowing
> > which alternative in a multipart/alternative you want looked at.
>
> Well, it's not an issue of "which alternative I want to look at",
> because even if the attachment counter obeyed my alternative_order
> rules, I prefer to look at the text alternative.
I mean which alternative you want the attachment counter to look at.
> Thus, for attachment counting purposes, we can reasonably decide to
> ALWAYS count *only* the attachments within the last alternative in a
> multipart/alternative MIME section. That's the one that should best
> reflect the "original" content, and thus that's the one that best
> reflects the intention of the user. It's technically possible to have
I think the RFC is leaves a lot of room for ambiguity, and this isn't
necessarily what anyone wants to happen, but I'll agree that it seems
like the most defensible last effort possible.
> If you want to add a config option to allow it to count ALL
> alternatives, that's fine by me, but I think counting only the last
> alternative is perfectly reasonable and compliant.
When this code was a patch, long back in the 1.3 days, there was a
means of instructing mutt how to descend containers while counting
attachments. IIRC we decided to drop that in favor of simplicity.
It was more important to me to get the code pushed upstream than to
maintain options.
> The thing I like about this idea is that if someone sends a
> multipart/alternative that has the attachment in an earlier component
> but not a later component, we can point to the RFC and say "you're
> doing it wrong; the LAST component is the one that's supposed to have
> all the fancy stuff." (I.e. the choice to count only the last
> alternative is a defensible one.)
Not necessarily. The RFC says that if the alternatives are unequal
(whatever that might mean), then the last is the richest. What if the
first is HTML with an inline addition, and the second is a PDF with all
content inlined within the PDF? This isn't incorrect because the HTML
is not richer, fancier, or more faithful than the PDF. It just requires
more parts (in this hypothetical case; certainly this is not necessary
for any hypothetical case.).
> I think it all depends on what you mean by "intent". Another way of
> looking at it is that Apple sent me her original content, formatted
> exactly the way she wanted, and additionally sent me a text-like
> representation of what she sent, just in case I can't render HTML.
OK, instead of "intent" let me amend my previous statement to say "best
representation in an unintended encoding of what she meant for you to
see". I don't think it changes anything dramatically.
> > The best combination of efficiency and accuracy for this message
> > would have been:
> >
> > multipart/mixed
> > |-> multipart/alternative
> > | |-> multipart/mixed
> > | | |-> text/plain
> > | | |-> application/pdf (reference, no content)
> > | | `-> text/plain
> > | `-> multipart/mixed
> > | |-> text/html
> > | |-> application/pdf (reference, no content)
> > | `-> text/html
> > `-> application/pdf (referent)
>
> Yeah, but... that's so ugly and inefficient, I don't blame Apple for
> sending a smaller, simpler message (that complies with the letter and
> original spirit of the RFC).
It's not really. Maybe it's ugly if you don't like looking at structure
documents and suddenly you have to, but this is very straightforward and
reasonable and not at all inefficient for a computer to process. A MIME
boundary is very cheap. Maybe it looks cleaner to consider it as:
<message>
<alternative-set>
<alternative>
<text/>
<pdf reference="blah"/>
<text/>
</alternative>
<alternative>
<html/>
<pdf reference="blah"/>
<html/>
</alternative>
</alternative-set>
<pdf id="blah">
</message>
That's not very ugly or inefficient, as XML documents go.
> By the way... would mutt's attachment counting view that as three
> attachments or only one? (Yes, I know multipart/alternatives are
> ignored, but let's say the structure was flattened a bit.) In other
> words, does mutt's attachment counting understand references?
Nothing in mutt understands references. When being counted, a
MIME component is evaluated strictly by its Content-type and
Content-disposition.
--
-D. dgc@xxxxxxxxxxxx NSIT University of Chicago