On Tue, 22 Feb 1994, John Lowry wrote:
Then there is no problem. Make RIPEM an RFC and use it. Just because there
is something PEM-like that is more popular than PEM doesn't mean that PEM is
broken. It isn't a matter of purity either. RIPEM is RIPEM and makes no
bones
about it. PEM is PEM and offers a set of services which RIPEM doesn't (and
which
Since RIPEM is so popular, all "pure" PEM implementations will need to
support it for backwards compatibility. It would be a lot easier if
RIPEM's methods were incorporated into PEM so that future PEM authors
knew exactly what they needed to implement to be PEM-compliant and also
work with all existing implementations.
the RIPEM documentation admits). If popularity were the standard then we
would
all be using VMS or DOS or something. :-)
Ah, but in their own subset of the computer industry, VMS and DOS _are_
standards. :-)
Your argument is similar to one which
states that because Xmodem gets the job done and is so popular that
obviously there is no need for TCP/IP.
Xmodem doesn't make any assertions about trying to be TCP/IP-like, but
RIPEM does make assertions about trying to be as compatible with PEM as
feasible. No TCP/IP implementor in his right mind would think that
Xmodem needs to be implemented as well, but a PEM implementor needs to
seriously consider RIPEM compatibility or lose a substantial section of
the market. Rather than have two competing PEM "things", let's just have
one.
I wonder what will happen when the PGP guys eventually come to the table
to create a merged standard that keeps both camps happy? Will they be
told to get lost because they aren't "pure"? Frankly, this elitist
X.500-and-top-down-CA's-or-die attitude is starting to wear a bit thin
with me.
Cheers,
Rhys.