Perhaps I was unclear. What I meant was that when the BASE64
encoding of a pem message passes through an ASCII to EBCDIC gateway,
the characters of the representation are translated from ascii to
ebcdic. The message represented remains unchanged.
Formally speaking, when a message passes through such a gateway it ceases to be
in MIME format. MIME is only defined within the ASCII world. Once you leave it
you leave the standardization framework MIME was designed within behind. There
are literally dozens of interrelations between MIME (to say nothing of RFC821
and RFC822) and the use of ASCII.
Now, we went to a lot of trouble in the design of MIME to make sure it would be
possible to define equivalents that will work properly in the EBCDIC world. We
asked for and received a continual stream of guidance from EBCDIC users and
this substantially altered MIME in a number of nontrivial ways.
We avoided the use of characters for which there are no EBCDIC equivalents, we
limited the use of encodings (nested encodings in particular present a major
burden for translating gateways), and so on and so forth. However, this in no
way obviates the need for precise standards describing both how MIME is
implemented and used in the EBCDIC world as well as documents describing how to
gateway MIME into and out of such usage enclaves.
I had hoped that some of this work would be done by the BITNET community (which
I believe represents the single largest connected network using EBCDIC
equivalents of RFC822) and I have been ready and willing to participate in this
effort. However, the BITNET community, as embodied by the CREN's BITNET
technical subcommittee, felt that an essential first step was standardizing on
a single character repetiore. My ability to object to this, assuming I would
even want to, is somewhat limited since one of the first exercises conducted by
the 822 Extensions Working Group that produced MIME was to figure out just what
character we've all been using!
Needless to say, this initial item on the agenda clashes somewhat with my
desire to really get moving on gateway specifications. (This is a big problem
for me since I write and support gateways that have to do this sort of thing.)
It would also be unfair to say that nothing has been done -- there are, in
fact, a number of proposals for handling the gatewaying issues that have
already been put forward. Here are some possibilities that have been considered:
(1) Define the problem away. There are actually two ways to do this:
(a) Think of EBCDIC as simply an extra layer of encoding of the underlying
ASCII object. In order to read the object you have to undo the
encoding.
(b) Only translate headers and boundaries and leave the content untouched
(i.e. still in ASCII). You now have an EBCDIC wrapper around
ASCII MIME objects and the labels are all still intact and valid.
(2) Do deep translation, that is, translate as many bodyparts as can be
accomodated into their EBCDIC equivalents. In doing this change the
markers on the parts (charset being the obvious ones) to the proper new
values.
This requires a rather lengthy table of bodypart types and how to deal
with each one. In the case of PEM you can either record the initial
state of the internal material (i.e. is the stuff inside the
encoding/encryption ASCII or EBCDIC) or you can record the transformations
that need to be done (per your earlier suggestion). I note in passing that
this is not materially different than a bunch of other types, e.g.
PostScript (PostScript includes its own mechanisms for encryption and
encoding of data).
I don't want to go into detail in this forum about the pros and cons of all
this but I will say that the problems are compounded by the large number of
gateways currently operating and the interoperabity problems that will ensue if
only some of them start handling MIME properly.
Is there some other forum that you would prefer? My real interest is
the integration of PEM and MIME.
The issue of integration of PEM and MIME is entirely up to this group, I think.
But the issue of EBCDIC interoperability goes far beyond this -- PEM is just
one of many content-types whose opaque nature complicates gatewaying to EBCDIC
considerably. PEM does not present fundamentally different gatewaying issues so
I think this is just one of the many items on the agenda for the BITNET
technical committee. Of course, if we want to tackle this in the IETF it would
properly fall under the area of either the 822 Extensions Working Group or
whatever group is being formed to handle gateway requirements (there was a
preliminary meeting at the last IETF but I don't know if any group has been
consistuted yet). However, I don't make policy about who handles what
aspects of writing standards and recommendations. I just write the thing and
I'll work with whatever group is appropriate.
Ned