On Mon, 24 Jun 1991 19:43:32 -0700 (PDT), Mark Crispin wrote:
If this is what is adopted by the IETF, I fear that I will have no choice but
to consider it a SHOW STOPPER and seek some other standard for multi-part and
typed mail. This is a fatal flaw that would return me to RFC-1154.
The minor convenience that it buys 8/7 gateways is overshadowed by the MAJOR
cost inflicted upon every UA. It will force a UA to decode and copy an
encoded high level segment as part of the process of parsing the body. The UA
must also choose whether to keep the decoded copy around (a potentially huge
storage cost) or to re-decode the upper level every time it needs a segment
from a lower level (a potentially huge processing cost).
Hmm.
I want to avoid strong language here. Let's say that I see a very
explicit tradeoff. Mark makes a powerful argument for making that
tradeoff in one particular way. I can live with that way of making it,
and can actually do so quite comfortably, as long as there is agreement/
understanding of what goes along with it.
To back up and reprise: I don't trust self-appointed conversion
processes very much, whether we call them gateways or something else.
At the applications level, I think there is ample experience on the
Internet--and even with mail--for me to assert that such "gateways" have
been written that [at least some] reasonable people consider badly
broken, but whose authors are self-righteous about what they are doing.
This leads to an impasse in which the user loses (no matter what else
happens). I think that there is a potential for 8->7 processing, and
for conversions among the various forms permitted by the "message
bodies" draft, to create opportunities for this type of screwing up the
likes of which we have never seen before.
That is not to suggest that a converter or decoder that Mark writes
will get it wrong: quite the contrary, I would expect that he would get
it (whatever "it" is) right, and that, if there are problems, that he
will agree that there are problems and fix them. My problem is that
people will write these things who are not as aware of context and
implications, and who don't read RFCs as carefully, as Mark does. I
think they are inevitable. Perhaps I am being paranoid, but my model of
the world says that real robustness starts from the protocols, not from
the implementators or their implementations.
From my perspective, we are not talking about whether UAs or gateways
are "inconvenienced" here, we are talking about the potential of serious
information loss. Only after we minimize the possibility of information
loss is it reasonable to talk about convenience.
Now my first line of defense against the problems I fear is to
organize the transport protocol around the principle of "no conversion
in intermediaries at all--if you can't deliver what you received, as you
received it, then bounce the thing". I think that is a good principle.
If it were adopted and followed, then the problem of information loss by
intermediaries disappears, and I really do see this as a "who gets
inconvenienced by the message body coding rules" tradeoff. And, as soon
as I get far enough to see it that way, I think Mark is correct, for the
reasons he identifies.
The problem is that we have seen ample, persuasive, evidence that the
"no conversion" rule, no matter how it is written, is going to be
ignored in some cases. Some of those cases will be in real gateways
that have to convert protocols, mail headers, and character sets: they
have no choice. Others will be because sites will claim an implicit
authorization from the sender to do whatever they decide they need to on
the basis that, by pushing a message out onto the list, the user wanted
it to go through. I'm unimpressed by that claim, but, as the saying
goes, that an a half-buck will buy a pretty good cup of coffee around
here. The advocates of that position are pretty self-righteous about
it, too--they are protecting the flow of mail, and the users, and doing
what the users want--they may even be right.
But then, as a user who worries about information loss, I think there
are two protocol possibilities:
(1) Tell the intermediaries that, if they must, they can convert, but on
the only acceptable conversion is to "encapsulate" the message into
Base64 encoding. As Mark points out, this makes things convenient for
the translators and nasty for the UAs. I would add to his argument the
assertion that this inconveniences everyone in order to provide for a
rare case: if we believe the model in RFC-ZZZZ, the situation should
rarely arise and is basically associated with "what you do in an error
condition" rather than "normal case" behavior.
The advantage of this strategy is that I think it is plausible to hope
that, if we say to those intermediaries "don't convert unless you
absolutely have to, but, if you must, do exactly this simple and well-
specified thing", they will conform and get it right (even if, as I
expect, they interpret "absolutely have to" much more liberally than I
would like).
(2) Insist that transfer encodings, and hence transport-form
conversions, occur only at lowest body part level, as Mark suggests.
This clearly makes the UAs easier at the cost of making gateways harder.
OK, there are lots more UAs than there are gateways or MTAs, and this is
a sensible argument (I'll ignore the fact that one of the big arguments
for "change the message headers, not the envelope" from the early part
of the year was that it was easier to change UAs than MTAs).
Fine. But then we either need the potential for MTAs (in a gateway
role, at least) to do serious message parsing and rearranging (as
discussed above, a scary prospect given experience), or we need some
very explicit authority-delegation arrangement so that the originating
user can specify what in-transit conversions are permitted and who gets
to do them.
So, Mark (and others), the tradeoff I see here is between:
-- encoding at the highest level, encapsulation of entire messages
when appropriate, and a relatively relaxed attitude toward who can
convert (even if we wish they wouldn't).
-- encoding only at the lowest level, encapsulation of entire
structured messages prohibited, and a very narrow set of explicit rules
about conversions and the delegation of authority for them.
There is, of course, a third option, but I don't think we can get it
mixed up with mail protocols: encoding at the lowest level, no
conversions at all, and a protocol police with the power and the will to
keep software off the network that ignores the "no conversions" rule.
To say "we can be relaxed about conversions" in combination with "lowest
level encoding only" would be a show stopper for me, simply because I
think information loss and a lot of finger-pointing are virtually
certain consequences. I don't want to suggest that Mark has proposed
that position--as far as I know, he hasn't. But I think we all need to
understand all of the implications of the choices, which is why I see
"no low-level encoding" as having powerful transport implications.
--john