William H. Geiger III wrote:
> Of the messages that I have received 99% are RFC 822, the other 1% that
> are in MIME format the vast majority are so to support such worthless
> formats as text/html, text/rtf, vcard attachment and other worthless junk
> attached to the message. Occasional I will send/receive files via e-mail
> but uuencode works just as well as doing base64 mime attachments.
>
> MIME for the most part is "much to do about nothing" when it comes to
> e-mail and *forcing* users to switch when it is not needed is anything but
> a GoodThing(tm).
MIME is an important achievement in improved interoperability. As a
framework for sending structured information over e-mail, it serves it's
purpose quite well, I would say. As an european citizen I do not agree
with your "much about nothing" statement. Take the implications of using
non-ascii character sets in a message as a good example.
Having a dedicated body parser for one and every kind of email based
service seem to be so very unnecessary. And you still have to agree on
how to tag the message to be recognized on the receiver side. A good
MIME parser in combination with a configurable content-type dispatcher
should be sufficient for exchanging arbitrary structured information
over email.
Not implementing MIME capability in email applications today is just
stupid. And not having MIME as the base for exchanging structured
information over email is just as stupid. There are several good MIME
parser freeware out there you know, you don't need to do MIME from
scratch.
PGP should have switched to MIME (multipart/signed, multipart/encrypted)
as it's default format long time ago.
I do not find your statement about worthless formats (I would call it
content types) to be serious. It might be worthless for you, but it's
valuable for many others. With text/html at last, with the invention of
MIME and HTML, it's now possible to send enriched text messages in an
interoperable way. And HTML works just fine on non-graphical displays as
well, see the lynx www-browser for a good example.
No, on the contrary, increase the pressure on developers to fully
embrace MIME and to give up their old/proprietary/non-interoperable
email formats or at least not use it by default.
And about using uuencode in a RFC822 body instead of MIME and base64:
Uuencode was dismissed many years ago as a broken binary encoding, in
internet mail gateway environments in particular.
Tomas
> Of the messages that I have received 99% are RFC 822, the other 1% that
> are in MIME format the vast majority are so to support such worthless
> formats as text/html, text/rtf, vcard attachment and other worthless junk
> attached to the message. Occasional I will send/receive files via e-mail
> but uuencode works just as well as doing base64 mime attachments.
>
> MIME for the most part is "much to do about nothing" when it comes to
> e-mail and *forcing* users to switch when it is not needed is anything but
> a GoodThing(tm).
MIME is an important achievement in improved interoperability. As a
framework for sending structured information over e-mail, it serves it's
purpose quite well, I would say. As an european citizen I do not agree
with your "much about nothing" statement. Take the implications of using
non-ascii character sets in a message as a good example.
Having a dedicated body parser for one and every kind of email based
service seem to be so very unnecessary. And you still have to agree on
how to tag the message to be recognized on the receiver side. A good
MIME parser in combination with a configurable content-type dispatcher
should be sufficient for exchanging arbitrary structured information
over email.
Not implementing MIME capability in email applications today is just
stupid. And not having MIME as the base for exchanging structured
information over email is just as stupid. There are several good MIME
parser freeware out there you know, you don't need to do MIME from
scratch.
PGP should have switched to MIME (multipart/signed, multipart/encrypted)
as it's default format long time ago.
I do not find your statement about worthless formats (I would call it
content types) to be serious. It might be worthless for you, but it's
valuable for many others. With text/html at last, with the invention of
MIME and HTML, it's now possible to send enriched text messages in an
interoperable way. And HTML works just fine on non-graphical displays as
well, see the lynx www-browser for a good example.
No, on the contrary, increase the pressure on developers to fully
embrace MIME and to give up their old/proprietary/non-interoperable
email formats or at least not use it by default.
And about using uuencode in a RFC822 body instead of MIME and base64:
Uuencode was dismissed many years ago as a broken binary encoding, in
internet mail gateway environments in particular.
Tomas