emacs-orgmode
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Orgmode] Re: using orgmode to send html mail?


From: David Maus
Subject: Re: [Orgmode] Re: using orgmode to send html mail?
Date: Fri, 02 Apr 2010 08:34:13 +0200
User-agent: Wanderlust/2.15.9 (Almost Unreal) SEMI/1.14.6 (Maruoka) FLIM/1.14.9 (Goj┼Ź) APEL/10.7 Emacs/24.0.50 (i486-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO)

Vagn Johansen wrote:
>David Maus <address@hidden> writes:

>> Eric Schulte wrote:

>[...]

>>>I should have been clearer here.  I *am* using the multipart/alternative
>>>appropriately.  When a chunk of org-mode text is converted to html I am
>>>adding a single multipart/alternative block with two alternatives, both
>>>the plain org-mode text, and the html, so that users like me who prefer
>>>to see plain text can do so, and users of web clients like gmail can see
>>>nice markup.

>[...]

>> But I still feel uncomfortable with the current solution: Even if the
>> message created by current org-mail-htmlize is a valid MIME message (I
>> think so) it is a rather complex MIME structure and I have no idea how
>> other MUAs will display such a message.

>Complex? That is how most emails are structured today.

I cannot not speak of "most emails today" but grepping for the
multipart/ entity in my mail archive ranging back to 2003 gives:


 | multipart entities in message | number of messages |
 |-------------------------------+--------------------|
 |                             0 |               4208 |
 |                             1 |               3587 |
 |                             2 |                260 |
 |                             3 |                  8 |
 |                             4 |                  4 |
 |-------------------------------+--------------------|
 |                         total |               8067 |

To avoid a misunderstanding: By "complex" I refer to a message that
looks like:

<single text plain>
<multipart>
  <single text plain>
  <single text html>
</multipart>
<single text plain>
<multipart>
  <single text plain>
  <single text html>
</multipart>
<single text plain>

And is considered to be just one document.

It just makes no sense to create such a nested message: If the
recipient requires html markup than send him html markup.  Why such a
nested message?

Moreover: Even if this message complies with the specs it is out of
their scope.

My impression is that current implementation of org-mail-htmlize mixes
up two completely different operations: /Creating/ a MIME message and
/displaying/ a MIME message.  Because it is assumed that a MIME message
as given above will be displayed as a single document or message.  And
this assumption cannot be based on the MIME specs of RFC2045-2049.

In RFC2046, p. 23 it is explicitely noted:

"Conspicuously missing from the 'multipart' type is a notion of
structured, related body parts."

The relationship of the message parts in the example above: "We are
parts of a single document" is not transmitted.  This information is
not present at the recipient's side and a MUA is not obliged to
display all parts at once to be MIME compliant (cf. RFC2049).

And back to the purpose: The whole idea of sending html markup arouse
because some recipients require html markup to properly display the
transmitted information.  To achive this sending the entire plain text
as html markup in a single multipart/alternative is sufficient.  There
is no reason for ripping the original document apart, requiring a
certain interpretation of MIME messages on the client side.

Rhetoric question: Isn't this mixing up of sending and displaying
the problem of users who willingly or unwillingly send html messages
only?  They implicitely assume that the message will be rendered in
the same way on the recipients side as it is rendered for them.  Or
users who send out MS Word documents, based on their personal
experience that everybody they know is capable of displaying .doc
files?

 -- David

--
OpenPGP... 0x99ADB83B5A4478E6
Jabber.... address@hidden
Email..... address@hidden

Attachment: pgpJU393REmbg.pgp
Description: PGP signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]