Peter Pentchev wrote: > On Sat, May 16, 2020 at 04:55:11PM +0300, Peter Pentchev wrote: > > 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. > > Just one more point that I forgot to write: *of course* it's fine for > people to implement experimental things to see if they'll work... > within reasonable bounds, of course, like not implementing new > algorithm identifiers outside the space reserved for experimental > ones. But it is also fine for other people to say "okay, sure, you > have your experimental features, but I'll wait until they're > standardized until I do the work on implementing them myself; also, > let's discuss whether they are even needed."
Thanks for the write up, this mostly anwsers my question I had for Robert. Regards Stefan -- Signal (Desktop) +4915172173279 https://keybase.io/stefan_claas _______________________________________________ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
