ietf-822
[Top] [All Lists]

why not use *ML (was: format=flowed : why not use HTML?)

1998-08-18 20:47:21
Michael A Quinlan wrote:

I would like to vote in favor of this as well. Resources would be
better spent improving support for HTML in MUAs instead of coming up
with yet another format for flowed text.

Me too, but for a slightly different reason: history shows that we've
had enough trouble getting text/plain to be used properly.  By adding a

Oh yes. Some browsers used to add invalid parameters to content-type
and even sometimes to Mime-Version !-)))

I still have in my filesystem some of the mails I exchanged with Ed
Levinson in 1992 when we first discussed SGML transport by
e_mail. Most of the issues have been raised, discussed, solved and
quite nothing has never been implemented.

HTML e_mail is IMO not the solution. HTML is very complex, but in fact
very narrow. HTML is really not made for documents, it is made for
information.

I then suggest to skip a step and promote a XML e_mail. We could have
at least two DTDs : one for plain e_mail with coding white spaces and
carriage returns (see PRE element in HTML) and another model for
richer content, one of its elements acting as a PRE. The first one
will garanty backward compatibility with text/plain. We can also be
ready to integrate the XMLized version of HTML as soon as the new HTML
WG of W3C delivers it. Of course, the XML+XSL or XML+CSS browsers that
the vendors are preparing will have no difficulty to display such
messages...

BTW, I don't want to throw oil in the fire, but a XML DTD for
messages, ***including headers***, could be helpful, very easily
extensible through various mechanisms (new elements, new attributes),
and Unicode. Backward compatibility between XMLmail versions could be
organised using public XSL tree transformation rules.

The documentation world went from a GML syntax (very close to RFC822
headers) to SGML and XML (markup languages for structured data), the
wold is ready to use the XML-based products that Microscape is
building, and RFC822 is still RFC822.

This is not a dream at all. I would be very surprised if Jean Paoli @
Microsoft has no such project (or beta1-but-ready-to-ship version ?-)
somewhere in his office. E_mail is a too important part of the
information circulation process that MS wants to rule to be left by
them on the right side of the road..

</Daniel>