On Sat, 29 Jun 1991 16:29:20 -0700 (PDT), Mark Crispin
<MRC(_at_)CAC(_dot_)Washington(_dot_)EDU> wrote in response to one of my
messages.
On Sat, 29 Jun 1991 17:43:11 -0400 (EDT), John C Klensin wrote:
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.
I assume you mean "don't use 8 bit transport"?
Yes, of course. Sorry.
What I consider a "show stopper" is anything that makes RFC-XXXX impractical
to implement, especially if the sole perceived value of that thing is to make
things easier for RFC-YYYY people.
I assume that you mean "RFC-ZZZZ people" :-). The distinction is
important because, if I recall, RFC-YYYY was what led to the "wretched
solution", and I consider that a show stopper.
In case my previous note was not clear, my sense of the relative
importance of the two protocols is such that, if we have to make "ease
of accurate implementation" or significant performance tradeoffs between
RFC-XXXX and 8 bit transport, the former should win every time.
My concern with prohibiting transfer-encoding at the top level (which
I am rapidly backing away from) doesn't have *anything* to do with eight
bit transport, but it associated with a problem that RFC-XXXX has the
potential to get into all by itself. To reprise that argument a little
bit, if we have a real mail gateway (i.e., transport level change from
TCP to something and mail transport change from SMTP to something)
between the Internet and "something else", and it receives RFC-XXXX, it
has to have sufficient information available to make the appropriate
conversions. I think that, in this day and age of a mail internet that
is much larger than The Internet and of provisions for MX addresses that
may ultimately lead to some very strange places, pretending that we need
to worry only about the SMTP/TCP/IP internet is not acceptable (for the
record, I am not accusing you, Mark, or anyone else recently of taking
that position).
Now, as Tom Moore and others have pointed out, the gateway-writer's
job need not be especially easy, life is tough sometimes. But we must
insure that RFC-XXXX gives sufficient information, in sufficiently
stable form, that it is plausible to expect fairly ordinary mortals to
implement correct gateways. I took exception to the removal of
top-level transport encoding because I thought (and still think) that
permitting it would make the life of that gateway developer somewhat
easier. I think a persuasive case has been offered (whether or not I
agree) that the disadvantages are greater than the advantages. Given
that we have managed to restrict the number of content types and content
encodings quite a bit, and given an attitude toward additions to either
list that is only slightly more negative than the present text in
RFC-XXXX, I think there is an environment in which gateways can be
designed and implemented, so I'm not too upset about the prospect of
losing this one.
I believe that they MUST NOT. The
justification offered was that it makes 8/7 gateways easier to apply a
transfer-encoding on a top level rather than at the lowest level.
Not by me, or I was not clear. See above.
That does
not, to my mind, provide an excuse for the great burden that upper-level
transfer encodings would have on all UA's.
I clearly evaluated the probable burden differently, and, given some
design ideas, am reluctant to accept "all" at the end of that sentence.
But I haven't tried to implement one, and the conclusion would
presumably be much the same if "all" were replaced by "lots of".
If this makes 8/7 gateways impossible, I don't care. If the impossibility of
8/7 gateways makes working 8-bit MTAs impossible, so much the better.
No comment, other than "it doesn't, and 8-bit MTAs won't go away quite
that easily. :-) But your position on this is, and has been, clear.
I would ask only that, if you are ever tempted to find difficulties in
RFC-XXXX precisely because they would make 8bit transport unacceptably
more difficult, you avoid the temptation. I don't think that has been a
problem so far.
--john