ietf-822
[Top] [All Lists]

Re: My greatest fear

1991-08-24 04:45:18
Don't be obtuse.

Who is being obtuse?  I've gotten tired of these circular arguments, not to
mention wasting huge amounts of my time answering them.

I too am getting a little tired of this debate. But that does not eliminate
my need to reach closure on some of this.

Since it seems that we are no closer to moving to closure, perhaps it's time
to conclude that this WG is going nowhere.  What little has been produced is
shaping up as an unwieldy kludge tower.  Perhaps we should admit failure,
disband this WG, and shelve its work, until such time as people are ready to
work instead of play politics.

I disagree. The 822 extensions seem firm enough to me. The SMTP extensions
are the place where all the trouble lies (sorry to be so blunt, but that's
the way I see it). If the SMTP extensions were to evaporate, what major
problems remain in the 822 work?

What was needed was a compatible and interoperable method of specifying multi-
part message bodies, of typing the individual parts, and of providing a
mechanism for non-ASCII character sets.  What is being proferred is a hairy
mess to satisfy everybody's favorite idea of what should be in the ultimate
mail system; with no regard as to what is practical to implement, or what can
reasonably be expected to work in an interoperable fashion.

Again, I disagree. I think this characterization is wrong, histrionic, and,
frankly, close to hysterical.

RFC-XXXX was a noble attempt, but it seems clear now it is fatally flawed.  In
the name of maximum generality, it has acquired scoping gaps you can drive a
truck through, or in this case multi-level encodings.  I haven't even touched
on questions of some of the other silly states that are introduced (quick:
what does a character set mean with audio?).

Well, gosh, I don't know for sure what a character set means with audio. I
suspect that it is meaningless. Since a character set header is only supposed
to be honored FOR THE SPECIFIC TYPES THAT ARE DEFINED TO ALLOW SUCH
SPECIFICATIONS, and audio is probably not one of them, I guess it is
meaningless. But the only reason I don't know for sure that it is meaningless
is that I have not seen the final draft of the specification of the audio type.
Once I see it I suspect that the opinion I just gave will be confirmed; it
is meaningless and can be ignored.

Are you seriously going to claim that the fact that you can specify extra
headers in messages (right now at the outermost level, later in inner levels)
is a "scoping gap you can drive a truck through"? Sure, you can specify
additional headers. For example, I plan to use an additional header to supply
record formatting information I need on VMS systems. Why should you care about
this -- your system probably doesn't have record formats! The information is
not relevant to you, but it will help VMS systems provide hints to other VMS
systems about file formats. 

Even X.400 has a mechanism for specification of optional stuff that gets
defined outside of the formal specification (this was added in 1988; it was
sorely needed). Such extension facilities are necessary and more than useful --
they are vital. Without them you end up in the mess SMTP is facing now. Be
grateful for the things that are good about RFC822 here!

There is a MAJOR difference between specification of some nonsensical header
that will be ignored and the introduction of headers that change the way
messages are broken down and parsed. RFC-XXXX is closed in regard to the
latter; it is open in regard to the former. The latter presents serious scoping
gaps; the former is a harmless detail.

You can moan all you want about interoperability issues, and I'm certainly
willing to listen to concrete suggestions on how to tighten up the typing
system and whatnot. But YOU seem to be losing sight of the fact that
high-quality rules for message composition and structure are the one central
criteria for interoperability. In practice, no matter how tightly you screw
down the specifications of various types, you cannot display audio information
on a dumb terminal, video information on a teletype, and so forth.  These
advanced types of information are highly specialized and require special
handling by special equipment. This causes interoperability problems -- big
ones. But RFC-XXXX makes it possible to assign such material nice neat names
(and thanks to your work, names that identify the type of material involved
even though the recipient may never have even heard of the format used for that
material), and better still provides a consistent mechanism for passing such
information around and keeping it intact. This is the essence of the
interoperability than can actually be achieved -- make no mistake about it.

It seems to escape the minds of certain individuals that whatever is specified
in this WG will NEVER be generally implemented by the overwhelming majority of
e-mail UA's and MTA's.  None of it.  People freely banter around terms such as
"declare X broken" or "no more work should be done on Y" as if somehow the
issuance of an RFC will make things happen.  It won't.  What's more likely to
happen is that we'll get various non-interoperable subsets, none of which
interoperate with the most important one -- today's 821/822.  We have enough
trouble getting people to interoperate with 821/822.

It never escapes my notice, I assure you, and I'm not one for bantering around
such terms. I see nothing in RFC-XXXX that will block the interoperability that
is possible with these old systems (with the exception of nested encodings, and
I do agree that they cause interoperability problems). Of course, you cannot
display an image without a graphics display of some kind. RFC-XXXX cannot
mandate such interoperability. But just because we cannot mandate such is no
reason not to move forward and attempt to formalize the exchange of such
things!

Disgusted,

      Mark

I'm somewhat disgusted with your attitude as well -- I expected better of you.

                                Ned

<Prev in Thread] Current Thread [Next in Thread>