One cannot call 8-bit mail "simple" in the existing Internet because
it flatly is not supported. We have to be sure to implement a scheme
that won't mangle mail on the fly (such mangling surely will result if
hosts are widely permitted to perform 7/8-bit conversions on the fly).
I think Ran has captured the essence of the problem, and has managed to
do so without any name-calling. Let me try to review how we got to
where we are:
(i) We agreed, many moons ago, that many Internet sites will be running
with 7-bit transport forever. How many is not really relevant. We also
agreed that it is possible to transport anything we need to transport
over 7-bit connections, and RFC-XXXX was designed on the assumption that
7-bit connections would be used (choose from "mostly", "often", or
"usually" to complete this sentence).
(ii) There are communities out there who want to use 8bit transport
and want to use it in a responsible way.
{If you believe that this desire is reasonable, as I happen to do,
then ok. If you believe it is not reasonable, please just mutter to
yourself "there is no accounting for taste" and read on.}
The people who are most anxious to use 8bit transport seem to be most
anxious to use it within local communities that they can define and let
everyone else fend for themselves (presumably by using 7bit transport).
Some attached the term "enclave" to those local communities, and we have
been using it since.
There is reason to hope that the vast majority of the people who want
to use 8bit transport will, if given a normative and easy-to-implement
way to do that, follow those rules. That group presumably includes both
"new" 8 bit transport users and those who have just started sending 8bit
material over SMTP (7 bit) connections because they (i) didn't know any
better and thought it was ok, (ii) didn't have another model for doing
it and didn't see what harm it would cause, or (iii) didn't give a d**n.
It is possible that some of the folks who have been sending 8bit
already--in clear (to everyone but a few of them) violation of the
protocols will insist on continuing to do so. If they do that, the only
alternatives are moral suasion and/or passing the word that people
should not buy their non-conforming and network-hostile products. But,
since they see customer/market pressure to provide an 8bit transport,
they are much more likely to conform to a standardized way of doing that
if we provide one than to tell their customers that they can't have what
they insist that they want (and have already).
(iii) However much users don't like bounced mail, they tend to like the
arrival of mail that is trashed beyond recognition even less. Take my
word for it, or go observe the child's game often known as "telephone".
So we have a compromise position here, perhaps an unfortunate one, but
probably the best one possible. It implies that:
(a) if one wants maximum, as-guaranteed-as-possible, interoperability
across the Internet, with as few problems as possible one will never try
to send 8bit transport traffic, but will implement the RFC-XXXX
transport encoding types and be done with it.
This is clearly the right option for Mark's preferences as I
understand them, and may be the right option for Keld's.
(b) If one has some well-defined enclave, then it might be sensible to
implement 8-bit transport for use within that enclave. It might also
just be perverse, but we don't need to decide that. Doing so imposes a
bookkeeping problem and/or a requirement to be very careful about how MX
definitions and links are set up. The RFC-ZZZZ definition is intended
to prevent 8-bit traffic from ever accidentally escaping an enclave
because we have agreed that is a Bad Thing.
If the software decision-makers for the UAs and MTAs for a particular
host decide to define "enclave" in terms of what can be made to
work (i.e., to use the trial and error method), rather than in terms of
bookkeeping or link-knowledge, then either the user is going to see a
lot of bounces (I certainly would not like to "sell" that to users
either), or the users are going to need to know to whom 8bit traffic can
be sent (also a pretty nasty selling job), or that software is going to
need to be designed to deal with bounced 8-bit mail in a very
sophisticated way.
Such a software solution, in which things that bounce are converted by
the originating UA or MTA without user intervention, would be very
difficult. It is not impossible. I would not particularly recommend
that anyone try it except as an interesting technical exercise. But
the alternatives are not "that software" or "explaining to users why
they should know about transport details or generally put up with a
reduced quality of life". There is a third alternative, which is
exactly the alternative RFC-ZZZZ presumes: avoid the trial and error
method and send 8-bit traffic to only those people you know are able to
accept it.
If that "know" produces a null set, or you don't think it is worth the
trouble to keep track, then you just use 7bit transport all the time and
everyone is happy--no one has told anyone that they must be part of an
8-bit enclave.
To say this in a different way, we have two protocols here. One of
them, RFC-XXXX, is intended for widespread implementation on the
internet. I would hope, sooner or later, to see a requirement that it
be supported, at least in its minimal form. The second, RFC-ZZZZ is
intended to be weaker and to provide a specification at the level of "we
don't care whether or not you do this 8-bit transport stuff, we might
even prefer that you didn't, but, if you insist on doing it, then we
insist that you do it this particular way".
8-bit transport won't go away, no matter what we do. The goal is to try
to regularize its use so as to minimize damage, and then get on with our
lives. A lot of that "regularization" involves creating a protocol so
that the debate with the existing "8bitters" changes from a screaming
match in which one side says "don't do that, there is no protocol" and
the other side says "but we have customer demand, and that is more
important to us than any protocol". There is no way to resolve that
kind of argument unless we start developing models for kicking hosts
from particular vendors off the Internet. The target alternate
discussion has the first side saying "if you insist on doing 8bit
transport, here is the only valid protocol for doing so, please
conform". I would hope that the other side would just do that,
partially because it is typically very hard to stand up and say "our
customers insist that we be non-conforming" with a straight face.
Against that background, I don't see where the "show stopper" language
is coming from. If you don't want messages either converted or bounced,
and don't want to define and enforce an 8 bit enclave, then don't use 7
bit transport. For whatever it is worth, in spite of being the
principal author of RFC-ZZZZ, I won't lose any sleep if no one uses it.
Now, realistically, Keld, what I would do in your position, if I had
users who thought they cared about 8-bit transport, might first be to
try to talk them out of it: maybe it is more trouble than it is worth,
as Mark suggests. But, if they insist, I'd go arrange a deployment
model in which servers were prepared to accept 8bit, but no one turned
on the switches for sending it. And every several months, I'd run a
little interoperability test in which I probed servers to see who had
upgraded to 8bit capability and who had not. As a little autonomous
exercise to be run on a weekend evening, it probably would not cost much
to either set up or run. When the percentage got sufficiently high, I'd
start asking the remaining sites when they were going to upgrade so that
they wouldn't hold up everyone else any more. And, when it got to be
100%, I'd tell people to go ahead and turn on the intra-enclave "ok to
send 8bit" flag at their convenience.
That is not an elegant strategy, but it avoids most of what I infer
are your worst (and reasonable) fears. Seems to me that, if it takes
six months to full deployment, that is ok. And, if it takes five years,
that is probably ok too. And, if Mark is right and 100% support
intra-enclave never happens... well, we have all agreed that no one
really needs 8bit transport.
--john