The majority of PGP users are using 2.6.x and will be for a long time to
come. This is fact regardless of wether one likes it or not.
There is a lot of stuff in OP which just will not work with PGP 2.6.x.
Strictly speaking, a MUST-only implementation would be totally
incompatible with PGP 2.6 as it won't do IDEA or RSA. Armour is the
least of our worries there.
Switching formats for the sake of some MIME "purity" at the expense of
compatibility is a foolhardy gesture.
It isn't for "purity"; it is to make it easier for new implementors to
create compatible versions without unnecessary impediments. They can
obtain MIME toolkits more easily than Armour ones. Or even just let mail
programs handle the encoding of the binary data.
BEGIN PGP MESSAGE, PART X/Y used for multi-part messages, where the
armor is split amongst Y parts, and this is the Xth part out of Y.
BEGIN PGP MESSAGE, PART X used for multi-part messages, where this is
the Xth part of an unspecified number of parts. Requires the MESSAGE-ID
Armor Header to be used.
These formats for multi-part messages are not re-inventing the wheel, they
are the wheels that all current versions of PGP ride on.
The second, PART X, is a new invention in PGP 5 and thus not relevant to
"the majority of PGP users [that] are using 2.6.x".
I highly doubt that the MIME Message/Partial subtype is widely implemented
among the current crop of MIME "compliant" Mua's (considering that Mua's
like Netscape & Eudora do not make use of multipart/alternative it is
doubtful that few if any make use of Message/Partial).
So they're even less likely to implement yet another multipart message
scheme.
I am also STRONGLY against using Base64 encoding of PGP packets. IMNSHO it
should be allowed for special case implementations but SHOULD NOT be used
in general e-mail applications. All this servers to do is break all
existsing PGP implementations without any added benefit.
I'm not sure what you mean by this.
Ian.