On 26 Jun 2000, at 10:40, Chuq Von Rospach wrote:
> MIME has its flaws, but it's a reasonable way to layer new
> functionality in without rewriting everything from scratch.
Maybe... but one problem is that it only handles 'sections' and that's
pretty limiting [unless you use MIME *SOLELY* as a wrapper and then come
up with some other actual-message-format that you embed in a MIME
section]. For example, to include a picture or a graph along with an
email message works fine, sort of, if having it just hanging there
separate works for you, but it isn't so easy to write about or include
gracefully in your text [indeed, folks doing _real_ document file formats
go to a lot of bother to allow you to embed graphs, pictures, etc, in
documents and have that 'work' reasonable seamlessly both at the author
and client ends].
> .. The job
> of replacing SMTP would be immense. It'd sure have its advantages,
> but I'm not convinced it's worth the work. it'd be fun to think
> about, though.
There are two things we're tossing around casually here: one is SMTP, RFC
821, and the other is the actual message format, RFC 822. SMTP wasn't
intended to have a long lifetime [there's a reason why it was called the
'Simple' version] and it has proven to have HUGE problems [EXPN, the need
for IDENT, its whole approach to relaying, handling of MAIL FROM, etc,
etc, etc]... but that's, IMO, a different matter: in that case, the
culprit isn't the coming of HTML but rather the coming of spam, and
perhaps we can worry about that another day...:o)
As for the message format, we could say some things about the underlying
machinery --- perhaps the biggest gripe I'd have is that MIME [AFAIK]
doesn't allow parts of the message to interact. And so, for example, I
don't think it is easy to -efficiently- encode an image and then refer to
it from a separate MIME section. IMO, the "multipart" stuff in MIME is
mostly a not-very-elegant kludge and could stand some
rethinking/redesign...
And of course, you'll then run into my biggest gripe aboue where all this
is going: the heir apparent to the enhanced-email encoding (once we redo
RFC822 et seq to make it _carry_ this stuff more gracefully) is HTML and
is the most depressing part. HTML is, as I have said several times
already, without doubt the *WORST* candidate for "enhanced email" that
I've seen over the years... It manages to be both too little and too
much: it is too little in that its ability to express actual document-
format is truly pitiful [especially compared with the -real- document-
description languages]; and it is too much because along with <EM> and
<FONT> you get javascript, frames, tables [speaking of some markup
machinery that set document formatting back ten [twenty?] years!], etc.
so it is simultaneously hard for the author to make HTML display what she
wants displayed and hard for the client to render it properly... UGH!!!
Even RTF is better...
/Bernie\
--
Bernie Cosell Fantasy Farm Fibers
mailto:[EMAIL PROTECTED] Pearisburg, VA
--> Too many people, too few sheep <--
