V
Victor Engmark
Background:
Interoperability between email agents is becoming increasingly important
as they diverge more and more in appearance (e.g. graphical vs.
non-graphical), focus (e.g. speed vs. looks), and complexity (e.g.
ability to parse badly formatted emails). The situation resembles the
one which is at the point of being mended by XHTML and XSL.
Solution:
I believe the same approach as for HTML should be taken for email:
Define an XML Schema for valid emails, and implement extensions to
existing email agents to make sure the emails they produce validate
according to the Schema. The Schema should use a similar structure to
that of XHTML. Until properly implemented, user agents might include the
XML email as a MIME attachment.
Example 1:
There exist three schemes for where to put the reply to a mail, namely
before the mail being replied to, after it, or in between the contents.
By using XML, one can clearly indicate which part of the email is being
replied to in the different parts of the reply, and thus link them in an
unambiguous way, leaving the disposition of the mail to the client. This
way, nobody will have to read (much less format) something like the
following:
---------------------
Second reply
---------------------
Example 2:
There exist different schemes for indicating threading in emails, and
these are interpreted differently by email clients. A lot of persons use
email clients which do not use the English "Re:" to indicate a reply,
and this is also known to cause problems with threading correctly in
some email clients. Some email clients even regard all emails with the
same "Subject" value as belonging to the same thread. By demanding an
identification tag to be included in each email, and a tag to indicate
the ID of the email being answered, threading emails correctly would
become almost trivial.
Example 3:
Searching for an email or part of an email can be made simpler, as XML
emails will contain a lot of explicit structural information. E.g., in a
discussion group it would be rather easy to find every email that
replied to only a certain part of another email. This can be
particularly interesting if the first email is rather long, with
distinct topics which each branch into their own discussion.
Example 4:
Signatures can be enclosed by a <signature> tag, making the error-prone
(and de facto little used) "dash dash space" solution obsolete, and
making the process of building a relevant signature easy. On the client
side, this can make the creation and update of contact information
easier, as the postal address, photograph, telephone numbers etc. can be
extracted automatically from an <address> block.
Other benefits and extensions:
1. To facilitate email reading on devices with small displays, one can
easily extract the important parts of an email using XSLT. XSLT files
can be stored online for reference, or attached to the email.
2. XSL-FO information can also be referenced or attached.
I really hope XML email in some form or another will be standard soon,
as the present situation leaves much to be desired...
Finally, I have made an example of an XeMaiL shell (with comments), to
be filled in with values present in normal emails:
<mail message_id="">
<header>
<received-path>
<received>
<from>
<address>
<dns></dns>
<ip></ip>
</address>
</from>
<by>
<address>
<dns></dns>
<ip></ip>
</address>
</by>
<with></with>
<for></for>
<date></date>
</received>
<received>
...
</received>
</received-path>
<keywords>
<keyword></keyword>
...
</keywords>
<date></date>
<from>
<person>
<name>
<first></first>
<middle></middle>
<last></last>
</name>
<address>
<postal>
<street></street>
<number></number>
<postal_code></postal_code>
<country></country>
</postal>
<email></email>
<web></web>
</address>
<telephone>
<home>
<country></country>
<area_code></area_code>
<number></number>
</home>
<mobile>
<country></country>
<area_code></area_code>
<number></number>
</mobile>
</telephone>
</person>
<company>
<name></name>
<type></type>
<country></country>
<address>
<email></email>
</address>
</company>
</from>
<to>
<email></email>
<name></name>
...
</to>
<subject></subject>
<mime>
<version></version>
</mime>
<content>
<type></type>
<charset></charset>
<disposition></disposition>
<transfer_encoding></transfer_encoding>
</content>
<user_agent>
<name></name>
<version></version>
<uri></uri>
</user_agent>
<reply_to>
<email></email>
<name></name>
</reply_to>
<in_reply_to>
<message_id></message_id>
</in_reply_to>
</header>
<contents>
<answered_mail id="" part="">
I didn't find a better name for it at the moment. The
attribute "part" can be a serial number to indicate the different parts
of the old email being answered at different points in the new email.
</answered_mail>
<answer id="" part="">
... XHTML 2 or something similar ...
</answer>
Additional text, e.g. the adressing of a topic not adressed
earlier in the conversation.
</contents>
<signature space="preserve">X X ee M M aaa i L
X X e e M M M M a i L
X eeee M M M aa i L
X X e M M M a a i L
X X ee M M aaa i LLLLL
from /me</signature>
</mail>
Interoperability between email agents is becoming increasingly important
as they diverge more and more in appearance (e.g. graphical vs.
non-graphical), focus (e.g. speed vs. looks), and complexity (e.g.
ability to parse badly formatted emails). The situation resembles the
one which is at the point of being mended by XHTML and XSL.
Solution:
I believe the same approach as for HTML should be taken for email:
Define an XML Schema for valid emails, and implement extensions to
existing email agents to make sure the emails they produce validate
according to the Schema. The Schema should use a similar structure to
that of XHTML. Until properly implemented, user agents might include the
XML email as a MIME attachment.
Example 1:
There exist three schemes for where to put the reply to a mail, namely
before the mail being replied to, after it, or in between the contents.
By using XML, one can clearly indicate which part of the email is being
replied to in the different parts of the reply, and thus link them in an
unambiguous way, leaving the disposition of the mail to the client. This
way, nobody will have to read (much less format) something like the
following:
---------------------
Second reply
---------------------
Example 2:
There exist different schemes for indicating threading in emails, and
these are interpreted differently by email clients. A lot of persons use
email clients which do not use the English "Re:" to indicate a reply,
and this is also known to cause problems with threading correctly in
some email clients. Some email clients even regard all emails with the
same "Subject" value as belonging to the same thread. By demanding an
identification tag to be included in each email, and a tag to indicate
the ID of the email being answered, threading emails correctly would
become almost trivial.
Example 3:
Searching for an email or part of an email can be made simpler, as XML
emails will contain a lot of explicit structural information. E.g., in a
discussion group it would be rather easy to find every email that
replied to only a certain part of another email. This can be
particularly interesting if the first email is rather long, with
distinct topics which each branch into their own discussion.
Example 4:
Signatures can be enclosed by a <signature> tag, making the error-prone
(and de facto little used) "dash dash space" solution obsolete, and
making the process of building a relevant signature easy. On the client
side, this can make the creation and update of contact information
easier, as the postal address, photograph, telephone numbers etc. can be
extracted automatically from an <address> block.
Other benefits and extensions:
1. To facilitate email reading on devices with small displays, one can
easily extract the important parts of an email using XSLT. XSLT files
can be stored online for reference, or attached to the email.
2. XSL-FO information can also be referenced or attached.
I really hope XML email in some form or another will be standard soon,
as the present situation leaves much to be desired...
Finally, I have made an example of an XeMaiL shell (with comments), to
be filled in with values present in normal emails:
<mail message_id="">
<header>
<received-path>
<received>
<from>
<address>
<dns></dns>
<ip></ip>
</address>
</from>
<by>
<address>
<dns></dns>
<ip></ip>
</address>
</by>
<with></with>
<for></for>
<date></date>
</received>
<received>
...
</received>
</received-path>
<keywords>
<keyword></keyword>
...
</keywords>
<date></date>
<from>
<person>
<name>
<first></first>
<middle></middle>
<last></last>
</name>
<address>
<postal>
<street></street>
<number></number>
<postal_code></postal_code>
<country></country>
</postal>
<email></email>
<web></web>
</address>
<telephone>
<home>
<country></country>
<area_code></area_code>
<number></number>
</home>
<mobile>
<country></country>
<area_code></area_code>
<number></number>
</mobile>
</telephone>
</person>
<company>
<name></name>
<type></type>
<country></country>
<address>
<email></email>
</address>
</company>
</from>
<to>
<email></email>
<name></name>
...
</to>
<subject></subject>
<mime>
<version></version>
</mime>
<content>
<type></type>
<charset></charset>
<disposition></disposition>
<transfer_encoding></transfer_encoding>
</content>
<user_agent>
<name></name>
<version></version>
<uri></uri>
</user_agent>
<reply_to>
<email></email>
<name></name>
</reply_to>
<in_reply_to>
<message_id></message_id>
</in_reply_to>
</header>
<contents>
<answered_mail id="" part="">
I didn't find a better name for it at the moment. The
attribute "part" can be a serial number to indicate the different parts
of the old email being answered at different points in the new email.
</answered_mail>
<answer id="" part="">
... XHTML 2 or something similar ...
</answer>
Additional text, e.g. the adressing of a topic not adressed
earlier in the conversation.
</contents>
<signature space="preserve">X X ee M M aaa i L
X X e e M M M M a i L
X eeee M M M aa i L
X X e M M M a a i L
X X ee M M aaa i LLLLL
from /me</signature>
</mail>