Friends,
I have been tacit for the past several days, trying to absorb the new RFC
and all the comments coming in.
I am very distressed at where this effort is going.
Everything but the kitchen sink seems to be getting thrown in, in a
farcial effort to solve all problems for all time and to please everyone.
The scope of this effort has gotten completely out of hand. Before you
know it, we will out-X.400 X.400.
I suggest a dramatic cut-back in scope. With this in mind, I suggest the
following changes:
(1) Establishment of the following Content Types:
a) TEXT (!) unspecified character set text. This is what we have *NOW*.
Don't give me this bullshit that it is not useful. It has been useful
for 20 years, and it isn't going to vanish tommorrow.
b) BINARY unspecified binary data.
c) MULTIPART multiple-part messages
(2) Elimination of the version stuff. Versions are bogus. Invariably, there
is one that works, and none of the others do, and hence the version is
really a constant (be honest -- can your TCP do any TCP version other than
4?). This creates a new error state of version .NE. constant. I
understand the notion of providing for future changes. However, I am
convinced that any incompatible changes (as opposed to extensions) will be
done using a different name because of the "version is a constant"
phenomenum.
(3) Establishment of the following Content Encodings:
a) no special encoding (old RFC-821 rules).
b) QUOTED-PRINTABLE
c) some binary form (BASE64, uuencode, or whatever).
AND NOTHING MORE!!!!!!
We will, my friends, have our hands full getting this much widely
accepted and implemented. Once we have this as a base, *then* we can start on
the extensions -- particular textual or binary types, other encodings, etc. --
as SEPARATE RFC's.
We should limit our scope SOLELY to the basic mechanism. We can always
issue follow-on RFC's layering on top of the base.
Let me remind you once again that interoperability depends upon the
principle of "least common denominator." In the current RFC e-mail world,
this is RFC821/822 using the flavor of ASCII commonly used in the United
States. No pontification about character sets in our new RFC will change
this least common denominator. It is fine to talk about e-mail with your
name spelled correctly in your national characters, but if it violates that
principle of least common denominator your e-mail breaks down as soon as it
crosses your country's borders.
There is another principle at work, which I think has been totally
ignored: The Law Of Unintended Consequences. In this case, the Unintended
Consequence that I fear is that this RFC will become yet another blue sky
proposal destined never to see general acceptance. It is for this reason that
I urge a strong scaling back of scope.
I am not saying that any of the ideas proposed here be rejected. On the
contrary; I think that there are many excellent RFC's possible:
. A Representation of National Character Sets in Mail Headers
. X.400 Message Types in RFC Mail
. A Representation of National Character Sets in Mail (note this is different
from the first)
. A Representation of Video in Mail
. etc. etc. etc.
Please give serious consideration to this. We have split this down into
manageable chunks. I can (still) understand the entire proposal. However, I
don't intend to implement 90% of it, and there are things I want to do that
the current proposal doesn't provide for (WingZ spreadsheets as a content
type, anyone?). I'm sure others are in the same situation. What I'm
suggesting is reducing the base RFC to the *mandatory* parts, and leave all
the options to separate RFC's.
Otherwise, the Law of Unintended Consequences will kick in. I for one
would probably end up punting and continuing to use RFC-1154 (and I've been an
early and frequent critic of RFC-1154!).
Sorry for the length of this and the flaming. What you're seeing is my
shock at trying to implement this in place of RFC-1154 code at the same time
as other major structural changes. Not a pleasant discovery.
-- Mark --