>From: Steve Kent <kent(_at_)COM(_dot_)BBN>
>Subject: Re: PEM MIME Content-Type
>Date: Fri, 19 Mar 93 09:17:47 -0500
It was my intention to attend the Columus IETF to discuss the PCA
requirements we have. However I am unable to now attend, for personal
reasons. Peter Kirstein and Wolfgang Schneider will easily represent
the little I would have to say.
Further to my last WG participation, I have read further mime-mhs
internet-drafts.
It has been my belief that using MIME to represent all manner of
new-headers, rather than constantly defining new ones, is a clearly
good move, provided it doesnt yet require all UAs to be MIME-capable.
That is, if minimal MIME, whose headers convey the presentation
information, meets all the needs I expressed, then good! However thats
a far cry from MIME-capable X.400 UAs everywhere.
draft MHS/RFC-822 Message Body Mapping Mar 93
Mapping between X.400 and RFC-822 Message Bodies
Thu Mar 4 10:05:05 EST 1993
section 2, may be quoted:
The mappings have been specifically designed to provide
optimal behavior for three different scenarios:
(1) Allow a MIME user and an MHS user to exchange an
arbitrary binary content;
(2) Allow MIME content-types to "tunnel" through an MHS relay
(that is, two MIME users can exchange content-types
without loss through an MHS relay); and,
(3) Allow MHS body parts to "tunnel" through a MIME relay
(that is, two MHS users can exchange body parts without
loss through a MIME relay).
Other, related, scenarios can also be easily accommodated.
(1) would seem to meet my needs to convey secured-IPMs. And, it can
be performed transparently on the MHS/MTS boundary.
Note (3) doesnt cater; I need entire IPMs, not just IPM.body, or bodyparts.
The final note suggests (1) could be specialised suitably with some
appropriate definitions. Identifying binary content, allows one
to ignore that the 822 Content, which the MIME text represents, represents
an complete IPM. Given the content is now RFC 822, PEM (and/or MIME-PEM)
requires no change. the minimal MIME headers replaces, equivalently, the
suggested Content-Domain: field profile I suggested last time. "Other, related,
scenarios can also be easily accommodated" may presumably list any
presentation value. The abstract-syntax oid, suitably conveyed in the
MIME bodypart header, seems as good a manner of differentiating as any.
Sounds good.
However given one X.400 bodypart is precisely PEM, conveyed by the
MIME-PEM multi-bodypart, else securing an 822 message itself MIME, then
it looks as if X,400 UAs are going to have to MIME-capable after all.
>Peter,
>
> The introdcution of Content-Type was intended to facilitate
>profiling of PEM for MIME and X.400 environments. Discussion of
>profiles of PEM for these messaging systems is definately within the
>scope of this WG. I encourage you to contribute to the discussion of
>the PEM-MIME profile, and to initiate work on a PEM-X.400 profile,
>e.g., write an Internet Draft as a first step. Will you be at
>Columbus?
>
>Steve