I have received a number of public and private comments on my original
SMTP/8 and 822/8 posting. Let me attempt to answer the major comment:
* These ideas have been discussed on these lists before. Why are you
* bringing them up again?
Engineering solutions are not matters of absolutes but of cost-benefit
tradeoff. The other solutions being proposed on this list are just too
complex (and seem to get more complex with each passing month). I
believe that it is proper to reevaluate the assumptions that have lead
to this complexity.
The principles you advocate here are fine, but I disagree both with your
assessment and with your conclusion. Most of the discussion over the past two
months has been to nail down details. With the exception of the notion of
nested encodings, complexity has not been a major part of the issues we've
dealt with.
And in the case of nesting encodings the issue has been resolved in favor of
lessening complexity. How does the reduction in complexity the loss of
nesting encodings brought us fit into this "just too complex" scenario of
yours?
Much of the complexity results from an earlier "decision" that:
*ALL* *NEW* functionality *MUST* fit through SMTP/7 and 822/7.
Again, this conclusion is close to being completely without merit. Let's list
the points dealt with in the last month or so:
(0) 8 bit to 7 bit downgrading. Yes, this relates to 7 bit interoperability.
It is the only issue debated lately that does. But it is not an RFC-XXXX
issue, it is an RFC-ZZZZ issue.
(1) Nested encodings. Since your proposal still admits the use of encodings
for binary, you cannot simply eliminate the nested encoding problem
by changing the pipe size.
(2) Labelling of character sets used in message headers. This issue exists
in both 7 bit and 8 bit worlds.
(3) Labelling of character sets and the conversion of same. This has nothing
to do with 7 bit or 8 bit.
(4) The type/subtype hierarchy. Same result as (3).
With the possible exception of (0), you have failed to make a case that any of
these things would be resolved by 8 bit transport. Thus, as far as I can tell
your conclusion is erroneous.
I believe this decision is the source of much grief and must be
reexamined.
I disagree and I have demonstrated the basis of my disagreement.
I wholeheartedly agree that:
*ALL* *OLD* functionality must continue to interoperate with
SMTP/7 and 822/7.
That's nice. The rest of the world does not agree with you.
For this reason, we are ammending the "defacto" RFC to *REQUIRE* some
features that protect 7-bit mailers and mail-readers from the effects
of octets (like registered trademark) which, when bit-stripped, may
confuse SMTP DATA exchange or mail-reader parsing of "structured"
header fields.
I was recently bitten by an 8 bit transport bug that I had never even thought
of. What's going to protect us from all the 8 bit transport bugs you have not
thought of?
You argue that we need to exercise sound engineering judgement, and then you
come up with hacks like this. Yours is the worst hack of all, and I don't
need theory to tell me this -- it is operational reality that demonstrates
it for me.
I also believe that:
It is *HIGHLY DESIRABLE* that *NEW* functionality fit through
SMTP/7 and 822/7.
For this reason, I support the position that "binary" encodings should
result in lines of printable ASCII-7 not to exceed 78 characters in
length.
See my list above, and then explain to me how all the various points we've
discussed would be simplified by this proposal.
HOWEVER, all of the work to force non-ASCII-7 characters into 7-bits is
leading to more cost than it is worth.
Wrong. The problem is not the forcing of the characters into 7 bits. That's
not where the cost is. The problem is the identification and labelling
of what things are in what form. This is the crux of the matter, not the
savings of a bit. And you have not proposed anything that resolves the
labelling issues. Even if you restrict yourself to two character sets
(you cannot get rid of US-ASCII, so if you add AUC/10646 you then have two)
you then have to label things somehow.
I believe: We don't need all the extra header fields and questionably
parsable multi-part techniques. AUC/10646 and extensions to 1154 will
handle all of this in a simple, consistent fashion.
The questionably parsable format is RFC1154, not RFCXXXX. I have implemented
both. So have other people and they have duly reported the results of
these operational experiments on the list. You have not successfully
refuted these points in the past and you have not done so now.
But what you have done here is even worse. You have dragged a completely
separate, orthogonal issue back into the discussion under the guise of the
character set and transport path size issues. The choice of encapsulation
formats has nothing to do with the present discussion. And dragging it back in
under the pretense that it is relevant is politics, not engineering.
You don't have to agree, but as engineers you need to evaluate the
cost-benefits of what we propose compared to the alternative currently
under discussion.
I do this sort of evaluation constantly. The best way to evaluate this material
is to try and implement it. Have you done so? I have implemented both RFC1154,
RFCXXXX, and RFCZZZZ and I have evaluated them all. (I cannot implement
whatever 10646 is in the process of turning into since I don't know what it is,
and at this early date neither do you, really.)
You apparently do not do any of these things. Instead, you make claims that the
present set of problems under consideration can all be solved by adopting a
proposal of yours that is, at best, only tangentially related to most of the
issues under discussion here. What sort of engineering is this?
Ned