Jim Galvin writes:
My model of PEM is not that it carries rfc822 mail, ie its content is
not rfc822, rather that the application which uses PEM is rfc822 mail.
This is best supported by the fact that PEM expects as input an rfc822
message, it massages the body of said input message, and outputs the
same rfc822 headers with a massaged body. This massaged body is not an
rfc822 message; it is a possibly encrypted, possibly encoded, signed
rfc822 body.
I agree with the second sentence. I also agree with the third; PEM
accepts an RFC-822 message as input and outputs a body (suitable for
enclosure within an RFC-822 message) containing a protected
representation of the input RFC-822 message's body. In the first
sentence, though, since the application using PEM in the present case is
in fact an RFC-822 UA, PEM actually does "carry" (insofar as one who
doesn't do MTA functions can "carry") rfc822 mail, in the manner
described in Jim's second sentence. It's true that the input enclosing
RFC-822 headers aren't represented within the PEM encapsulated text, but
are rather passed through unmodified, alongside the PEM encapsulation; I
don't see why the analysis hinges on this point, though.
Before the Content-Domain: field, there was no way for a recipient PEM
UA to determine that the data represented within PEM encapsulated text
corresponded to anything other than the body of a vanilla RFC-822
message. The field makes it possible to build a dispatch facility so
that the data extracted by the recipient PEM can be passed for
processing by an appropriate entity above PEM. Given that we're looking
towards evolving PEM technology to provide protected transport for data
elements other than RFC-822 bodies, I think it's reasonable and
appropriate to support such an indicator independent of the question of
whether the "core" PEM processing itself needs to act differently for
different indicator values. Effectively, it's a "next protocol" field
for the PEM encapsulation layer.
--jl