Ned is saying that we should not complicate things for the multipart
people, in requiring things on them due to 8-bit mail.
Whoa. First of all, I'm not the one that started this discussion. Mark
Crispin is, if memory serves. And I don't think you've summarized Mark's
position adequately either.
I would argue the other way around....
Depends on your interests, it seems.
I disagree with this assessment. I want to use 8-bit mail. This is one of the
primary reasons for the multimedia/multipart mail extensions. It is not a
secondary reason.
You're confusing a goal with an implementation methodology. One goal is
to be able to send/receive 8-bit entities. Your methodology is to expand SMTP
to support 8 bits directly. You can send 8-bit entities in ways that do
not require the adoption of this methodology.
I see 8-bit mail as a natural way to extent internet mailings for
plain mail, the prime goal of mail.
Well, its nice that you think the primary goal of mail is to stay in the
dark ages, but this is totally irrelevant. Once again you're confusing goals
with methodology.
And this is to be done in the
area I live, namely Europe - and it is also needed many other places.
Multipart mail is a feinsmecker thing to me, I have never had the use
for it and most of my customers do not burn for it either.
As an aside, about half of _my_ customers are in Europe. Multimedia and
multipart mail are extremely important to them. I think your characterization
that Europeans are not interested in these things is incorrect.
I think that many of my fellow European collegues feel the same
like me, this was stated explicitely at the NETF meeting in Stockholm
(where the multipart messaging was simply explicitely removed from
the agenda because of lack of interest) and many other times from
Europeans.
The Europeans I deal with don't agree with you.
I know that we are only Europeans and that other people
may think otherwise.
A lot of your fellow Europeans feel otherwise. I've sold product to
Europeans on the basis of the features it provides in the multimedia
multipart arena that our competition did not support.
But I will *not* ask for the IETF to consider the multipart issue
for a less interesting issue and thus of less importance that
the 8-bit mail - (which must not just be seen as an *enclave*
issue, unless you want to see the whole of Europe being one big
enclave with a lot of gateways...). I just will ask you all to consider
the 8-bit mail a legitimate and natural Internet protocol - if the internet
is ever going to be meaning something related to "international".
Well, the fact that this discussion is occurring is an indication that
the IETF feels that these things are important.
And from this requirement I request the engineering people of the
multipart stuff to apply their greatest skills in designing
a multipart specification that is open to the (8-bit) world.
Oh please. This _REALLY_ galls me. The present multimedia multipart
specification offers a mechanism that allows cooperating UAs to use
8-bit material in their messages in a fashion that is consistent and
reliable. Two consenting UAs can start using this mechanism and proceed
to happily carry whatever 8-bit material they want across the net. No, repeat
NO, upgrading of SMTP is needed. No, repeat NO, interoperability problems
result.
There's no requirement to start using the multipart stuff, but it is there if
you need it.
Thus, from a pure "I just wanna do 8-bit text and nothing else and I want to
do it with a minimum of fuss" standpoint, the present multimedia multipart
specification seems ideal. All this stuff about translations, conversions,
who-does-what, and so on becomes entirely moot. This means that the present
multimedia multipart work _is_ open to the 8 bit world. In fact, it is
open in a way that 8-bit SMTP is not -- it has no interoperability problems
whereas 8-bit SMTP has plenty of interoperability problems.
But there's a sense that we want to drag SMTP, kicking and screaming, into
being able to process untransformed 8-bit text. This is where the problems
start. Whether you like it or not, systems that simply send and receive
8-bit material via SMTP are INCOMPLIANT and BROKEN. (I know, my software
has this problem presently. It won't once a way out of this box is provided.)
Why do we want to do this? Well, I don't. But a lot of people do, and their
desires are gonna get satisfied somehow, in my opinion. Thus 8-bit SMTP
becomes a goal in and of itself, independent of the need to carry 8-bit
material in mail, which can be done without using 8-bit SMTP (and the
multimedia multipart specification says just how to do it, either by
using 7-bit or 8-bit SMTP).
The remaining problems (which I thought were close to being resolved before
you brought this up) are limited to the case where an 8-bit message has to
be converted into a 7-bit message. (Maybe you don't think this is going to
happen, that everyone will be doing 8-bit right away. Dream on.) The
problem is that people don't like having systems piddle in their mail. This
leads to a number of possible approaches, which is what we've been discussing.
I don't care to cover the territory again, but I will say this -- the
basic conflict is what's simple for a converter to do puts a huge, repeat
HUGE burden on the UAs of the world, while a modestly more complex (and
hence possibly more error-prone) mechanism in the converters makes life
a lot easier for the UAs. There are then, broadly speaking, three possible
outcomes:
(1) Eliminate the problem by getting rid of converters somehow.
(2) Ream the UAs and make the converters simple.
(3) Make the converters slightly more complex and keep the UAs simple.
I refer you to the current discussion for the outcome of this decision.
Ned