Comments on the Schiller MIME/PEM Proposal
1) RFC1421 PEM allows for multiple PEM objects in a single PEM
message. A message with multiple PEM objects will be returned to
MIME in a format that is not easily manipulated, i.e., the
individual objects are not distinct. Note that this condition can
occur both for content-domains RFC822 and MIME if multiple MIME
objects are PEMed together.
Two solutions come to mind. The first is to prohibit multiple PEM
objects in a single Application/PEM-1421, and the other is to
specify some post-processing rules by which the multiple PEM
objects are returned in a MIME multipart format.
2) PEM provides (via the RFC 934 mechanism) for nested PEMed
objects. This is useful for forwarding PEMed messages and attached
comments. Because the nesting rules of RFC934 and MIME are quite
different, this is where most of the complexity of MIME/PEM
integration exists.
Nested PEM objects are handled by current software by recursively
running the PEM application on each subsequent level PEM object as
they are uncovered by RFC 934 processing. If the PEM object is
returned to MIME from PEM processing with only the immediate level
processed, the nested PEM objects will not be accessible via the
MIME mechanisms. It will be identified by a ----begin privacy....
boundary and not a valid mime content-type: Application/RFC1421.
The same solutions as identified for issue 1 can apply, that is,
prohibiting the nesting of PEM objects eliminates this problem, but
also renders current PEM software less useful than it may otherwise
be. Additional post processing rules for the PEM-1421 type can be
defined to require detecting the nested objects and converting the
nested PEM object to a multipart MIME object. The PEM application
would need to return the PEM object with nested objects in a MIME
multipart format with content types text/plain and
application/rfc1421. MIME can then detect the nested objects and
call the PEM application for each one.
An example of a nested PEM object in the MIME context similar to
the one provided in the Crocker, Freed, Galvin, Rose draft would be
very helpful in understanding how these message structuring issues
would be addressed.
Greg Vaudreuil