Hal Finney <hal(_at_)rain(_dot_)org> writes:
Many of them are related to the MIME convention you describe of separating
control information from data. This works well in an email environment,
where such separation is already in place. We have mail headers and body,
and it is natural to add the MIME control information to the headers,
and to put the MIME body parts into the body. This also works for HTTP
and news, which have a similar header/body distinction.
But this model breaks down when we are in an environment where such
separation does not exist. [...]
The only way that I can see to support this with PGP/MIME is to make
the file consist of the MIME headers, then a blank line, then the MIME
body parts. In effect we adopt a convention that files do have two parts,
control information and data, and that they are separated by a blank line.
We are forced to do this if the file system does not provide us with
another place to put lengthy control information, as most do not.
Sounds reasonable, and the way that I would expect MIME encoding to be
implemented in files where this is required.
You could view armor as already having this same two part structure
.. it has to have a blank line (in pgp5 ... pgp2.x did not have this
restriction, btw). So with armor your header is:
: -----BEGIN PGP MESSAGE-----
: Version: 2.6.3i
and the body is:
: -----END PGP MESSAGE-----
Where they are separated by a blank line.
Same thing for MIME, header:
: Content-Type: application/pgp
: Content-Transfer-Encoding: radix64
But since this convention cannot be applied uniformly throughout the file
system, ambiguities arise. There is no way to tell a priori whether a
file is in this new "MIME format" or whether it is an ordinary file.
If it is a MIME format file, it will have Content-Type: etc. fields
saying what kind of PGP object it is.
Same as the armor header.
I personally am accustomed to armor because my mailer uses it and
because I haven't bothered installing direct MIME support.
However it seems that MIME is the way forward, and that having Armor
as a MAY allows implementors to implement it for backwards
I think neither MIME nor Armor should be MUST. Both MAY. You could
argue for SHOULD for backwards compatibility.
(Note: with IDEA and RSA relegated to SHOULD or is that MAY already,
backwards compatibility is already lost for a minimal MUST only
A minimal implementation should be allowed to call itself OpenPGP
compliant without implementing either MIME or armor.
You might need to define some new MIME types to go with rfc2015 for
the MIME types for the objects which you say are missing.