Michael G Schwern writes: > David E. Wheeler wrote: > > > On Apr 18, 2008, at 10:50, chromatic wrote: > > > > > My argument was complex: solve the real problem or don't solve it. > > > The in between position is silly and won't make anyone happy. > > > > Yes. The choices, as I see them, are: > > > > 1. Do we start out conservative, and loosen things up as the cow > > paths indicate (Ovid's position)?
An example of this would be saying: We promise that all future 'official' keys will start with a lower-case letter. It is prohibited for you to start an in-house key you create with a lower-case letter. > > 2. Do we start out liberal, allowing anything, and formalize > > whatever turns up in the cow paths (what I'm now suggesting)? An example of this could be saying: All current 'official' keys are lower-case (and start with a letter) and we expect future ones will be as well. If you choose to create an in-house key which starts with a lower-case letter then you risk a clash in future should we happen to introduce a key with that name. In practice, what's the difference between those two? The first is apparently stricter, but the prohibition can't actually be inforced: if a user chooses to ignore it then we can't send him to prison or anything; it's just that there's a (small) chance of his system later failing. Similarly if the future Tap maintainers bizarrely do create a key named in some other way, whether they are breaking a promise or a mere expectation doesn't make any difference: it isn't like users can sue over a broken promise. So since choice 1 can't be enforced, it seems to behave exactly like choice 2 anyway. > The prefixing solution sucks, but it's all we have... and that's a bad > place to be. Rather than arguing about a sucky solution, does anyone > have another solution to offer? In practice users can name keys however they want. Namespace clashes will be a bigger issue for some users than others. Issue advice on how to mitigate the problem and let users choose whether to follow it: It's possible that a key you pick will also be used by somebody else for a different purpose, which could cause problems if your systems later get used together. You can reduce the risk of name clashes by starting all your keys with a standard prefix or your organization or project name (or something else likely to be unique). Smylers
