On Sat, May 16, 2020 at 01:36:10AM +0200, Stefan Claas wrote: > Peter Pentchev wrote: > > > On Fri, May 15, 2020 at 10:54:32PM +0200, Stefan Claas wrote: > > > > You know what, the most interesting thing of this ML for me is that > > > when people, do a request or suggestion the old guard is always > > > there to defend some standard and are not accepting that a new > > > product on the OpenPGP market, with a new feature included, add an > > > enrichment to a given standard, which people may like to use and > > > appreciate. > > > > OK, but *how* is it an enrichment? What does a UID-less key provide > > over a randomly-generated UID? Why go to the bother of supporting a > > new special case when you can get the same result in another way, > > with zero additional code in any of the existing implementations and > > only a couple more lines of code in the special client that will have > > to generate a random UID? > > Fact is this function is available for users of OpenPGP software.
Is it though? It is not part of the OpenPGP standard, is it? It is available for users of software that implements the OpenPGP standard *with some local extensions*, which is a bit different. > We should better think of how this will pan out in the future, if users > start to use OpenPGP software with UID-less public keyblocks and how > GnuPG users can interact with them, or not? GnuPG users can interact perfectly well with people who use OpenPGP software :) As Robert J. Hansen said, if you (or somebody else) want to extend the standard, there is an IETF working group and mailing list for that. The way I see it, there are two types of standards: - ones that are discussed and written before being implemented, so that all the implementors have the same idea and nobody comes up with, say, using the same magic numbers for completely different purposes or having a function accept one more argument than anyone else and break if it is called with fewer arguments - ones that standardize existing behavior, like the POSIX standard for operating systems, system calls, libraries, command shell, etc. Now, I've been on the POSIX mailing list for well nigh 20 years now, and let me tell you, trying to standardize something when different implementors have come up with *all kinds* of slightly different ways of doing *almost* the same thing can be... crazy. Insane. Amazingly, astonishingly, horrifyingly weird, and very time- and nerve-consuming. It seems to me that the people involved in developing the OpenPGP standard did, at one point, decide to go the other way: yes, sure, start with the existing PGP and GnuPG and other implementations, but then, when thinking about future work, decide to discuss things before implementing them (recent threads on the OpenPGP mailing list notwithstanding), so that it is sorta kinda expected that once various implementations gain the new features, they *will* be able to interoperate. That sounds... kind of reasonable to me. G'luck, Peter -- Peter Pentchev r...@ringlet.net r...@debian.org p...@storpool.com PGP key: http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13
signature.asc
Description: PGP signature
_______________________________________________ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
