On Sun, 18 Aug 1991 13:54 PDT, Ned Freed, Postmaster wrote:
A multipart PEM message needs nested encoding facilities
I believe that PEM should be considered a different level from the encoding
mechanism of RFC-XXXX. I would be very surprised if it ended up being a
Content-Transfer-Encoding. So I think this is a non-issue.
If you mean that, in broad terms,
a UA should know that something of a particular type requires some generic
form of display (e.g. you cannot do much with audio without a speaker, you
cannot do much with image without a graphics display, etc.) then I agree. I
see no attempt to change this.
Yes, this is more or less what I mean. I'm perhaps more interested in a
"statement of principle" added than any actual changes to what is there now.
I would prefer to coalesce the top level into TEXT, BINARY, MESSAGE,
MULTIPART, and APPLICATION (although I'm not sure that I or the authors of
RFC-XXXX really know what APPLICATION means). But, in the spirit of
compromise, I can live with the current nine types (adding TEXT-PLUS, AUDIO,
VIDEO, IMAGE) as long as we have a "statement of principle" that avoids an
explosion of top-level types that really belong in one of the 9 categories.
Please identify the open ends more explicitly and we'll see about closing
them.
I'm not really sure what APPLICATION means. It looks like a place-holder.
AUDIO, VIDEO, and IMAGE with a subtype other than G3FAX look like place-
holders too. Do we really want G3FAX, or FAX/G3 (that is, a FAX subtype which
in turn has subtypes).
I expressly want to avoid what I call "silly behavior".
I'm not sure how an RFC, especially one that does not cover the unstandarized
terrain of a UA, can possibly enforce this. I agree that such behavior is
silly. I agree that it should be avoided.
I am not interested in enforcement as much as I am interested in guidelines
being written for implementors. In many cases the implementor has no clear
understanding of what his implementation may deal with, and may in all
innocence may make a design decision that leads to silly behavior. Often
silly behavior requires two agents at cross-purposes, usually accidental.
What I'd like is for us to think of the various possibilities, how they are
caused, and how they should be prevented. For example:
SILLY BEHAVIOR: 7-bit ASCII message received encoded in BASE64.
CAUSE: Message was composed on site in 8-bit world for delivery
to a 7-bit site. The 8->7 gateway used converts all
messages to BASE64.
CURES: Origin should clearly label message as 7-bit and if possible
not use gateway in this case. Gateway should recognize
that conversion is not necessary in this one case (where
stripping the 8th bit is the right thing to do). Gateway
should recognize textual messages and use QUOTED-PRINTABLE
encoding instead of BASE64.
[Note that any one of these cures would break the silly behavior.]
Nested encodings in particular offer myriad possibilities for silly behavior.
Of course, it does require scanning messages, which in turn
breaks the "MTAs don't touch message bodies" concept. Maybe this concept is
the thing that's wrong. I'm beginning to think that it is.
I agree that this concept is wrong.
to imply the complexity of X.400 and the complexity of nested encodings are
similar is simply not realistic; they are at entirely different orders of
magnitude.
True, but I'm getting the nasty feeling that we're going to have to do it
anyway. The worse RFC-XXXX/new-SMTP gets (and it's really the latter that's
the problem), the less warm I feel towards the idea of messing with our
existing infrastructure in what is likely to prove to be a futile attempt to
head off X.400.
I know how to implement nested encodings in my implementation; it's only a
dozen or so lines of code. But, it will be VERY VERY slow. To support nested
encodings so that it doesn't take a week would require a redesign; more likely
an implementation of what the cretinous gateway should have done in the first
place -- undo the nested encodings so that the message is in its component
parts, and re-encode the message correctly.
Perhaps I should make it automatically send a message to the owner of the
gateway, the original sender of the message, and the IAB giving a CPU time
report of how costly this bad gateway implementation that we're proposing to
sanction is going to cost UA's. 1/2 ;-) (?)