[Users] [Bug 2787] Support multipart/related inside multipart/alternative for HTML Views

[noreply at thewildbeast.co.uk]

http://www.thewildbeast.co.uk/claws-mail/bugzilla/show_bug.cgi?id=2787

--- Comment #12 from Ricardo Mones <mones at users.sourceforge.net> ---
(In reply to comment #11)
> Paul, what it tells us is that this structure of email is far more common
> than I thought. Thunderbird produces this structure quite often apparently
> since I'm getting a crazy amount of mail with this structure from
> Thunderbird users. So now I can easily provide samples.

Being produced just by one version of one MUA is not exactly my definition of
"common" :-)

Given that uniqueness and the number of bugs such MUA has in its MailCore's
MIME component, I'd say it's just another one.

> The anticipation is that it would be covered in Claws' repertoire of
> structures it can parse and display in Fancy by selecting/promoting the HTML
> part automatically when set to do so.

That reminds me of something... can you test the patch on #3028 and see if
improves promotion of those wrong structures to you?

> I didn't reopen the bug but does the availability of sample emails to test
> the scenario make it a case for an open RFE?

The samples are not good as discused before ;-)

Anyway, in my view a jpeg cannot be ever an alternative to a text part, look at
this (reiterated) definitions on RFC 2046 (arrows are mine):
┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈
(1)   multipart -- data consisting of multiple entities of
          independent data types.  Four subtypes are initially
          defined, including the basic "mixed" subtype specifying
          a generic mixed set of parts, "alternative" for
→         representing the same data in multiple formats,
          "parallel" for parts intended to be viewed
          simultaneously, and "digest" for multipart entities in
          which each part has a default type of "message/rfc822".
┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈

those jpeg are not an alternative format for the text part unless it's a jpeg
of the written text, which i've never seen.

Another one more precise, later on same RFC:
┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈
5.1.4.  Alternative Subtype

   The "multipart/alternative" type is syntactically identical to
   "multipart/mixed", but the semantics are different.  In particular,
→  each of the body parts is an "alternative" version of the same
→  information.
┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈

Key is "same information", the jpeg doesn't carry the same information as text
part, the html does, that's why it's an alternative.

I hope those clarifies this to you.

-- 
You are receiving this mail because:
You are the assignee for the bug.