The possible decision of people to go with 8bit in place of MIME is a
non-starter. The main reason is that doing so, without also converting
to MIME, is to continue sending unlabled objects of various content
types.
The demand for different content types is very low compared to the
demand for good national character support.
This begs the question of whether these are in fact separate issues.
In my opinion they are not and cannot be dealt with as such.
My conversations with European sites running our software (which constitute a
significant fraction of our customer base) indicate that support for different
content types is especially important _because_ of the need to handle national
characters correctly. While part of this need can be met with the extension of
plain text to accomodate character sets other than ASCII, this does not tell
the whole story. Many different structured document formats are used precisely
because they properly handle national character sets in ways that plain text
simply cannot.
Time and again I hear requests for support of more document formats, more
conversion facilities, automatic type detection and labelling, and so on.
And, of course, all these things MUST handle mutiple character sets properly
and as a matter of course. But neither is the more important -- they are both
requirements that must be met in order for things to work properly in
complex internationalized environments.
This discussion of which is more important is an exercise in futility. Both
needs are important, as are many others, and we are trying to accomodate them
both this set of needs as well as many others.
I must observe that just sneding 8bits has never been a solution to the
problems of sending different character sets in RFC822 mail bodies. It
will only get you some small efficiencies in sending unlabelled objects.
The efficiency is not the driving force, it is the functionality,
handling national characters with todays equipment.
I happen to agree that efficiency is not the issue, but this all depends on
who you talk to.
The nicest thing about MIME and RFC-ZZZZ is that they make it possible to
build mailers that interoperate properly with old systems, both incompliant
ones that send and receive 8 bit data, and compliant ones that insist on
7 bit data. These documents also make it possible to work nicely with new
systems that are more aware of what's going on.
But again, discussion of which of these systems is more important is futile.
Everyone views their mix of systems as being representative of what's
important. Can't we just admit that all of these things are important
and let it go at that?
It is not a good solution. It will not be a good solution tomorrow
either, or next year, or the year after that...\Stef
*I* know that, *WE* know that. The problem is that the typical new site
does not know it. They are not interested in reading RFCs, nor do they
have the time to do it. They are not interested in computers other than
as tools to do their work.
And as such, they will quickly come to care about what's going on when
things do not work properly. With a MIME compliant and RFC-ZZZZ compliant
mailer it is possible to make all sorts of combinations of systems
work well together. And this is the driving force I want to see exploited.
Some years ago most terminals, terminal emulators, printers etc, used
7-bit national characters, and there were no bigger problems with sites
sending non-7-bit mail. Today almost all equipment delivered use 8859-1,
but the delivered mail programs does not convert back and forth. You
can not blame the local system installer, he just installs what is
delivered, and does it according to the installation manual.
Absolutely true.
Thus we have to provide him with the tools needed. And as so many of the
new sites are commercial companies, a solution for just universities alone
does not help. Most commercial sites don't want to run software that
is not provided by the vendor they bought the computer from.
My solution is to offer commercial software that implements MIME as well
a freeware that does the job. I cannot become the vendor of the system itself
unless they choose to license my code, but there are plenty of sites that
don't insist that everything come from the hardware manufacturer.
Ned