Re: multipart/alternative question
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
On Thursday, July 16 at 01:40 PM, quoth David Champion:
>> 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.
Sure, I can swallow that. "Faithful to the original content" is...
well, like you said, makes no guarantees about the content.
But here's the thing, I think the most important thing is to be able
to distinguish between 0 and >0 attachments; it's less important to
get the 1 vs 2 vs 30 attachments count exactly correct, because it's
the 1-vs-0 count makes a mutt user decide to look at the mime
structure. It'd be nice if we could make the attachment count perfect,
but I think it's a bigger problem to mistakenly say there are zero
attachments when in fact there is at least one and maybe more.
> It was more important to me to get the code pushed upstream than to
> maintain options.
I can respect that.
>> 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.).
That's an excellent example! Let's be a bit more precise, just for
argument's sake:
I 1 <no description> [multipart/alternative]
I 2 |-><no description> [multipart/mixed]
I 3 | |-><no description> [text/html]
I 4 | |-><no description> [image/gif]
I 5 | |-><no description> [text/html]
I 6 | |-><no description> [image/gif]
I 7 | |-><no description> [text/html]
I 8 | |-><no description> [image/gif]
I 9 | `-><no description> [text/html]
I 10 `-><no description> [application/pdf]
The problem is that the current attachment counting code would look at
that and report that there are ZERO attachments, when in fact there's
at least one (the PDF) and maybe more (all the image/gifs).
I think we can make a reasonable argument that, based on the RFC, an
attachment count of 1 is valid, if not perfect. There may be
reasonable arguments to say whether a count of 1 or 3 or 4 attachments
is more preferable. But I think it's absolutely indefensible (from a
MIME-parsing perspective) to say that there are 0 attachments in such
an email.
On the other hand, if we have a message structured like this:
I 1 <no description> [multipart/alternative]
I 2 |-><no description> [multipart/mixed]
I 3 | |-><no description> [text/html]
I 4 | |-><no description> [image/gif]
I 5 | |-><no description> [text/html]
I 6 | |-><no description> [image/gif]
I 7 | |-><no description> [text/html]
I 8 | |-><no description> [image/gif]
I 9 | `-><no description> [text/html]
I 10 `-><no description> [text/plain]
I think we can make a pretty good argument to say that this is a
poorly formed email (not that I can't imagine some really circuitous
arguments along the lines of "the user wanted to send text/plain, so
adding images was technically less-faithful"), and that in that case,
our attachment counting is allowed to be wrong.
Here's another thought: perhaps the attachment count for a
multipart/alternative should be the maximum of all of its components.
Thus, in both this case and the previous case, the attachment count is
3 (which is a reasonable value, if not a perfect one).
Of course, like I said, I'm more worried about incorrectly saying
there are 0 attachments when there is in fact (at least) 1 than I am
with incorrectly saying there are 3 attachments when there are in fact
(depending on how you count) 4 or even just 1.
>>> 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.
I don't like the idea that "correct" MIME representation requires
references. I think MIME references are a hack. Not that I can defend
that opinion, though. :)
~Kyle
- --
The whole art of government consists in the art of being honest.
-- Thomas Jefferson: Rights of British America, 1774
-----BEGIN PGP SIGNATURE-----
Comment: Thank you for using encryption!
iQIcBAEBCAAGBQJKX347AAoJECuveozR/AWeCjgP/2YqcxyrUk+p6HUQbuPdNOSX
rH2/v5QDaeuvqI0mdEHx7FvrkdoqZMJqbbe7Vf9rd7krPozdpYMw3LG4wjoc2qdz
yPlfSK6gWS9ZyPp8YgTuQHDRLk1PE+9i6hnksQxb+8LiZhWri0MdUi1zduiBn/V7
uzedK13GHRmJGkidq4OgKAg+MtBLKmNP6LNp3vA3vx3/L27WQX8xXbhrPSzSPu88
5omZaTyqCGh18Dm+Bk+kLIee8YArazRXVJ+t+O8jBhyb2hHF4kIE/J+eMv9fOwHv
EnAVLg0ALTLRBK0ICRtrFZekuK85TvBptYdp85YytIuXx21rd442geedQ6OzSI5l
KOzYzuMBX4V6Qmit9akme9xPK1gpg8YtwSnXxyd2hgPaf+RWAvwnWieXHIXmMCO/
zf+rRztW6AHYstfUfKO1ixyLmT/xMDayZ7kgke1/oYvZshZa3abwGANKu7WAL1o0
0KL/m51xgla8WqsEqadBCXroGc6Z2UAKNQiIf8IoTwoC6zJEBR62HSqkY077si6J
0RQSI4Jlx1pNhBn0FhHNPU5NA+104AA2n/GefGSR1MjZ0QbWSD8j4FmMELFZClEp
rWMRx8UHgkhobkH85PIss8+c+TfMgDZA2QCz/5oAa4A2OIsIzPwfSMEVDUts/5TS
MhTNPXn838o5OMusSnU9
=/0Rx
-----END PGP SIGNATURE-----