Adam Back wrote:
This of course will be problematic for programmers, as they test their
code against 5.x, and discover the strange packets.
This problem highlights the usefulness of the extension mechanism Jon
Callas described briefly. If PGP implements controversial extensions
as extensions, the compatibility problem vanishes -- implementations
which don't have the extension coded already have a defined way to
safely ignore it.
I agree that it would be nice to have a defined extension mechanism.
There are lots of things one could do with the PGP infrastructure if one
had the time, and a decent way of adding some extra features.
My normal rule is "no change" and I've pushed that on many occasions
here. That's probably because I'm old and tired and have been on the
business end of many a programmer's last minute addition. They are
usually simple in the mind of the proposer and a nightmare, or worse,
for everybody else down the chain of software deployment.
However, given the trauma caused by the CMR feature and the likely cost
to the credibility of the standard if this goes in, I think a change is
needed here. The addition of the extension mechanism would (as a MAY to
provide and a MAY to ignore and a SHOULD or MUST to not blow up) might
be sufficient to provide the flexibility to replace the CMRK, for those
who have decided it is a good thing.
I don't however see this as a problem, as there is little to stop
PGP Inc from publishing a separate document which can become known.
As the programmers are coding up the pgp code, and as this feature
is only used by PGP Inc code, they know where to ask.
I'd sooner discourage them also from using the CMR feature at all, due
to the security risks, and negative political aspects. However, if
they insist, it's their reputation, but I would think a good way to
implement it would be to implement it using the extension mechanism.
Well, it is not up to the IETF or anyone to stop any company from
shooting itself in the corporate foot. The standard should be neutral
on that, and not try and discourage such and such a feature.
OTOH, it should definately not leave the way open for generations of
programmers to copy footwear ventilation features into their code.
--
iang systemics.com
FP: 1189 4417 F202 5DBD 5DF3 4FCD 3685 FDDE on pgp.com