Re: Suggestion: XML support
I guess this topic is most appropriately addressed on the mail-ng
list. Announcement attached.
On 2004-02-02 20:24:32 +0100, Victor Engmark wrote:
> From: Victor Engmark <victor.engmark@xxxxxxx>
> To: pine@xxxxxxxxxxxxxxxxxx, mutt-dev@xxxxxxxx
> Date: Mon, 02 Feb 2004 20:24:32 +0100
> Subject: Suggestion: XML support
> Organization: CERN
> X-Spam-Level:
>
> The short version of this email is that I am tired of the compatibility
> level between email clients, and I think XML is the answer to improve it.
>
> The longer version
> ------------------
>
> 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 on the web, 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. Until properly implemented, user agents might
> include the XML email as a MIME attachment. The header values in the
> XeMaiL (everything home-brewed needs a nice nickname, don't you think :)
> would override the values in the "original" email.
>
> By defining application-specific XSLT files as well, one could enable:
> - conversion from otherwise incompatible email readers, and
> - picking out only the bits _your_ email reader knows how to understand.
>
> When people get more used to write semantically instead of only
> graphically, one could use application-specific XSL-FO files to define
> how to display emails. That way users would have an easier time finding
> just the header information they are looking for, and power users could
> easily tweak the setting files themselves, as XML is rapidly becoming
> more used.
>
> On top of all this, once the XSD, XSLT and XSL-FO files have been made,
> they will not be made obsolete for a long time.
>
> 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:
>
> ---------------------
> > How about two o'clock?
> >
> > > Any suggestions?
>
> Sounds good
> ---------------------
>
> Instead, the contents can be formatted thus:
> <email id="55" answers="42">How about two o'clock?</email>
> <email id="42">Any suggestions?</email>
> <email id="13" answers="55">Sounds good</email>
>
> ... or thus:
> <email id="13" answers="55">
> <email id="55" answers="42">
> <email id="42">Any suggestions?
> </email>
> How about two o'clock?
> </email>
> Sounds good
> </email>
>
> It will be relatively easy for any email client to sort these email in a
> proper order before displaying the result, and line-breaking issues will
> vanish.
>
> 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 many
> distinct topics which each branch into their own discussion.
>
> Example 4:
> Signatures can be enclosed by a <signature> tag, making the error-prone
> (and rarely used) "dash dash space" solution obsolete, and making the
> process of building a relevant signature easy. On the client, this can
> make the creation and update of contact information easier, as the
> postal address, photograph URL, telephone numbers etc. can be extracted
> from an <address> block.
>
> Attached is the first draft of an XML Schema to validate "XeMaiL".
> Please reply whether you are interested in adding support for XeMaiL to
> your email reader, and I will help you as much as I can.
>
> I really hope XML email in some form or another will be standard soon,
> as the present situation leaves much to be desired...
>
> (Much of) this email has also been sent to Microsoft Office support and
> Mozilla.
>
> --
> Victor Engmark
--
Thomas Roessler · Personal soap box at <http://log.does-not-exist.org/>.
--- Begin Message ---
Greetings again. There seems to be more discussion these days about
replacing SMTP and/or RFC 2822 and/or POP/IMAP for a variety of
reasons. The discussion seems to pop up on a few different lists and
in a few different hallways, and it might be good to have a single
list where folks can congregate. Thus, I have set up a mail-ng
mailing list.
The first task probably is to determine what the next generation of
mail should do, and how that is different than what
SMTP/2822/POP-or-IMAP or instant messaging does. It is safe to say
that we can ignore actual protocol proposals for many months (if not
years) until we figure out what is needed. Once we do that, there are
plenty of protocol people who can attack the decided-on requirements.
There is no expectation that there will be significant agreement on
the list. It is likely that over time the discussion will split into
camps of like-minded design goals. The list might then spawn
different lists for the folks of the different camps (mail-ng-shoe,
mail-ng-sandal, ...). The list is explicitly not yet meant to be an
IETF working group yet (if at all), and is probably more akin to the
IRTF. But at the beginning, it will most likely be talking, not
research.
See <http://www.imc.org/mail-ng/> for information on how to
subscribe. The list is taking subscriptions now, and will probably go
live for discussions within a week. Having some discussion on a
mailing list now should make the dinners and bar gatherings at Seoul
more interesting.
--Paul Hoffman, Director
--Internet Mail Consortium
--- End Message ---