I've been trying to be quiet, but I feel compelled to jump in briefly,
perhaps against my better judgment:
Imagine, for a moment, that a group of people who have no connection
with the Internet world go off and develop a brand-new hypothetical mail
system that has to have 8-bit transport. (Perhaps they'd call it by
some dumb name like "X.400". :-) ) Now, they have their own [growing?]
mail world, and we have ours. It will clearly be in the interest of
both worlds for there to be gateways, and it is not legitimate, in my
opinion, for the people in either world to specify that such gateways
are "not permitted."
This is, I believe, precisely the situation we will have if RFC-ZZZZ or
something like it takes hold: a clearly defined, separate 8-bit mail
world. If people want to build gateways between this and 7-bit RFC-XXXX
mail, more power to them. I think that, while we should not
gratuitously complicate their lives, neither should we bend over
backwards to plan for them in advance. In other words, I agree with
Mark that the requirements of such gateways should not make us tolerate
the added complexity of nested encodings, NOT because such gateways are
a bad idea, but because bending over backwards to accomodate them in
advance is a bad idea. A gateway will still be practical with the kinds
of restrictions Mark wants to add -- I doubt that it will complicate
things by more than 10 or 20 percent.
In other words, the proposed restrictions are fine, but lets not
exagerate their import -- they do NOT make gateways impossible, only
slightly more complicated. They make life sufficiently easier for the
RFC-XXXX implementors that it is worth a bit more pain for the gateway
implementors, especially since the former will probably be much more
numerous than the latter. -- Nathaniel