Please let's NOT revisit the requirement that nested encodings are prohibited.
There is a scaling problem as soon as you allow nested encodings. If you nest
encodings then you make it impossible to determine the structure of a message
without going through one or more decoding steps. Each decoding step involves
a copying of data and a nesting of state.
MIME data can be very large, larger than can be feasibly handled on small PC's
and Mac's. Furthermore, it is presumptious to say that the UA will be doing
the work. In distributed mail protocols such as IMAP, it is quite possible
that a server will be doing the work; it may be necessary to analyze the 50MB
of MIME before deciding what (if anything) is downloaded to the client. What
may be an acceptable cost to a single-user client may be an intolerable burden
to a shared server. Personal CPU's have gotten faster and more resource-
capable, but data transfer bandwidth has not increased at a corresponding
rate.
No technical justification has been offered for why PEM requires nested
encodings. I've been told repeatedly that the structural data conveyed by
MIME is not intended to be ciphered by PEM; and that the sole reason for
forbidding nested encodings is to prevent the ciphering of MIME structural
data. Rather, the excuses, as conveyed to me, are (paraphrased somewhat):
1) Having followed a particular design path for some years, the PEM group is
unwilling to modify their design to conform to MIME and rather wants MIME
to conform to PEM. The fundamental problem is that PEM wants to be at the
top structural level of a message, conflicting with MIME.
2) The architect of PEM, being on IAB, is politically powerful and has the
clout to push through architectural decisions no matter what technical
objections may exist.
If these charges are true, then I fear that IETF is heading down the garden
path that ISO followed. I will grant that this was told to me in the context
of a `it does not matter what the right thing may be, the PEM group will not
consider it because...' pressure tactic.
I hope that the PEM people turn out to be more reasonable than how they have
been presented to me, and that we can come up with an acceptable
representation of PEM data in MIME. From my understanding of the PEM
protocol, a fair amount of work that is presently done by PEM becomes
unnecessary in a MIME context. I hope the PEM group would recognize that it
would be a worthwhile exercise to consider PEM as part of the MIME
infrastructure rather than how to shoehorn the existing separate PEM and MIME
infrasturctures together.