A bit more context on why relying on Dave Thaler isn't the long term strategy, below.
On Sun, Jul 19, 2020 at 10:20 PM Martin Thomson <mt@xxxxxxxxxxxxxx> wrote:
On Mon, Jul 20, 2020, at 14:18, Larry Masinter wrote:
> I blame RegisterProtocolHandler because before it was really hard to deploy
> a new scheme, so it wouldn't matter who owned pizza:
I don't agree that registerProtocolHandler is the root cause. That's a symptom of a deeper malaise. I'm running Windows and poked around in my registry a little. The number of entries under HKEY_CLASSES_ROOT that specify 'URL Protocol' are pretty shocking. Some use the reverse domain name thing (com.microsoft.print3d:) and others are entirely unqualified (feed: and feeds: appear to route RSS to Outlook; acrobat: routes to Adobe's PDF viewer).
I can only conclude that the victim passed long before registerProtocolHandler arrived on scene. The URL as a means of addressing programs and providing context is too useful to leave to the privileged few.
That my computer likely has a completely different set of functioning URL schemes to any other is just one of the problems that come from this. But we should not pretend that the IETF has any amount of control over what happens. We have some influence, but that depends on how relevant our response is.
Right now, the gap between reality and the registry is largely down to Dave Thaler registering a ton of these (including feed:, above). Relying on Dave is not really a long-term strategy.
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.
regards,
Ted Hardie
