Hi Ted, > On 21 Jul 2020, at 3:12 am, Ted Hardie <ted.ietf@xxxxxxxxx> wrote: > > As others have noted, there are a bunch of different things you can optimize when running a registry. When the scheme registry was in operation under RFC 2717 and 2718, at least some folks were trying to use it to minimize the total number of schemes in existence (a common question was "Why can't you do this with HTTP?") and the gatekeeping aspect of it meant that every registration had to satisfy a pretty skeptical audience of its utility (see Section 2.3 of 2718). > > By the time we started working on RFC 4395, it was obvious that this gatekeeping had not really worked--people minted URI schemes readily, but they didn't register them. The scary potential result of that was collision, and there was at least one such scheme (mms) that drove a lot of the desire to shift to optimizing collision avoidance instead of scheme minimization. The creation of the provisional registration was an effort to lower the bar enough that folks would register them and explain at least what the security considerations for the scheme were. That lowered bar was still "Expert Review", though, and there was still an expectation that the individual who minted the scheme was the registrant. > > RFC 7595 lowered the bar even further, so that provisionals can be registered on a first-come first-served basis, provided the template supplied is actually complete. Further, the template was radically simplified so that scheme syntax, scheme semantics, encoding considerations, interoperability considerations, and security considerations were all removed from the template and shifted to the scheme specifications where those are supplied. The result is it is now possible for a third party to register schemes that they encounter, provided they can identify a contact and change controller; they need know nothing else. So anyone who cares can imitate Dave's work when they encounter a scheme that has not been registered. > > That optimization, to make the registry as complete a record as possible of schemes present in the wild could, of course change. But it was driven by a real concern that unregistered schemes could collide with each other or registered schemes. Before adjusting the registry again, I'd like to understand what's being optimized by the new approach and what the theory is for meeting the original driving concern. That's a good summary. To me, the question is whether there are ways to avoid spurious / vanity registrations without creating unnecessary barriers to entry. The balance we settled on in the well-known and link relation registries was to require a specification, but to allow the Expert(s) to register values that are in wide use, in consultation with the community. Personally I think it's working out reasonably well; it prevents registration because someone had an idea in the shower (too early), while allowing registration of something that's actually getting adoption in the wild (which is the problem that Dave was trying to solve AIUI). Stepping back, I do think we should continue to experiment with and adjust registry policies based upon feedback from their users. Allowing a request to be made via an issue queue is showing some early promise, and I think we could expand that. Eventually, it would be good to align policies *where it's appropriate*, but I think we've got more to learn before we go there. Cheers, -- Mark Nottingham https://www.mnot.net/
