ietf-822
[Top] [All Lists]

Re: My greatest fear

1991-08-20 20:13:49
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.

We are so close to agreement (which is itself pleasing) that I'm reluctant
to push this point. However...

I didn't say, and I don't think, that PEM would be a new transfer encoding.
PEM is defined presently to use an existing transport encoding. It may
not get represented as such, but I think this would be a mistake.

However, this is not the point. The point is that PEM implies encryption,
and as a result encoding, of entire messages, including all their parts.
Encryption/encoding on a part-by-part basis is not acceptable; it reveals
too much. Since PEM is defined on a canonical text format, to PEM binary means
that you have to encode the binary as text first. The result is a nested
encoding. It does not matter whether we use RFC-XXXX conventions or not (I'd
like to since it does not make sense to have two equivalent but different
formats) -- you have nested encoding to deal with.

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.

There was a bunch of discussion about fleshing out APPLICATION in Atlanta.
A couple of people took revisions to this type away as an action item. I don't
know if this made it into the minutes or not.

I'm comfortable with this as a placeholder for now.

If you have an idea of what the statement of principle should contain, please
send it to me.


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).

IMAGE/whatever is going to be used initially by the NETFAX people. The
current proposal there is to go with something like NETFAX/TIFF/B/NETFAX.
The G3FAX type will be eliminated.

Once we have a video working group, or a color image working group, or
whatever, I expect we'll see additional use of IMAGE that is similar to but
different from what the NETFAX people are doing.

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.]

This may be breaking new ground for RFCs. I have no objection to having a
"silly behavior" section in there somewhere. If you want to flesh this out
some I'll see what I can do with it.

Nested encodings in particular offer myriad possibilities for silly behavior.

Of course.

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.

Now all we have to do is convince everyone else...

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.

Actually, I'm getting the opposite feeling. I don't think we'd be having
such a confrontation if it weren't for the fact that people really want to
use this stuff.

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.

I have the advantage of being able to change thing in more extreme ways, I
guess. It took more code, but I was able to do it fairly efficiently.

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 ;-) (?)

No comment...

To summarize: I'm pleased that we're basically in agreement. We're both
opposed to nested encodings; we differ only in how opposed we are. I don't care 
to predict how this is going to end up -- I'm proceeding in my implementation
on the assumption that it could go either way.

Let me make one additional point. RFC1154 does not present any real
alternatives that change this stuff in any real way. Once you add a
mechanism for nesting parts to RFC1154 you have the same exact problem that
RFC-XXXX has with nested encodings.

Now, you can build a different strategy that keeps all levels of encodings in 
the main header, but this has the problem that the main header gets very 
complex and composition of messages becomes a nightmare because of all the
poking and prodding the header then needs (I don't regard the implementation of 
a very complex header parser/tweaker as much different from scanning the whole
message). It is, in any case, not the extended RFC1154 approach to nesting that 
was posted earlier.

With this in mind, I'd like to dispense with using the RFC1154 approach as a 
counter-example/whipping-boy/threat. The critical part of the Prime proposal is 
their approach to SMTP extensions: declare 8-bit legal and 7-bit broken. It is 
that part that eliminates nested encodings, not RFC1154. You could layer that 
part of the Prime proposal on top of RFC-XXXX and you'd eliminate the need for 
nested encodings. The developers of RFC-XXXX were careful to make sure that
this was possible; RFC-XXXX is deliberately SMTP-extension-neutral.

                                Ned


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