warning: i have been spoiling for a fight all day :-).
But the important thing is that, if I may speak for the diehard "no
conversions" community, we would read the above narrowly, agree with it,
and then say something with which you might have a problem. E.g.,
(i) Every smtp client that supports 8-bit transport MUST be able to
support 7-bit transport and SHOULD be able to do 8->7 translation. Not
being able to do so is not nonconforming, but is really stupid.
you're right, i have a problem with this. every 8-bit transport MUST be
able to 8->7 translation.
(ii) relays are not smtp clients, and don't convert. Relays should
not accept mail in 8-bit transport form unless they are sure that they
can make final delivery in that form (whatever "final delivery" means).
an smtp client is in my view any process which opens an smtp connection to
another host. as such, relays can be smtp clients (of other relays or of
end-nodes). relays must be able to convert.
the ideal i'm striving for is that we add the same functionality everywhere.
8-bit transports are being designed here in a time when we know all about the
7-bit transports, so taking the 7-bitters into account seems pretty cheap.
i'm also striving for an incrementally valid solution which will have zero
cost in network bandwidth when the whole network is someday converted to
8-bit transports. granted we have a permanent design complexity such that
even when the whole network has been converted, new 8-bit transport implem-
entations will have to be able to deal with nonexistent 7-bit transports
in order to be "compliant". that's not cheap but i'm proposing it anyway.
The only thing that is wrong with doing it [vixie's] way is that we have
moved beyond simple character mail and into very complicated stuff in
which it may be very hard to guarantee "straightforward 1-to-1
mappings".
"very hard" is not relevant. you can represent any data structure in a
7-bit-wide data stream. look at C-language source code for examples.
look at uuencode and atob for more examples. it can be done and done
reliably. (such a design would include an application-level checksum
for all the reasons clark et al have outlined in their end-to-end paper.)
Some of the things RFC-XXXX is designed to pass around are
not "mostly readable" (or even a little readable) in any form--8-bit,
7-bit, baudot,...--and none of the transformations we are contemplating
make things any worse (or better).
i would be willing to punt close-readability, though we could optimize
for the trivial (and common) case of 8-bit single-part text that just
needs the 8th bit for accents and other non-ascii symbols. anything
else could just be bitblasted into atob or uuencode or whatever structure-
dependent format people are currently considering. (i will design this
part if noone else has done it.)
[...], the odds of ending up with a no-loss 1-1 mapping are much
higher than if that converter has to read, parse, and understand a
complex body part structure.
either we design it correctly or we don't. either the design is implemented
correctly or it isn't. i don't understand "hard" as a design-criteria here.
anything that is easier than X.mumblefrotz is not "hard" and is still a win.
cheers,
--
Paul Vixie, DEC Western Research Lab
Palo Alto, California, USA "Be neither a conformist or a rebel,
<vixie(_at_)decwrl(_dot_)dec(_dot_)com> decwrl!vixie for they are really the
same thing.
<paul(_at_)vixie(_dot_)sf(_dot_)ca(_dot_)us> vixie!paul Find your own
path, and stay on it." (me)