URI 方案（即 git+ssh://）中的分层协议是否有公认的标准或替代表示法？

Question

首先让我说我知道 git+ssh:// 示例不是一个很好的示例，因为它是多余的，在实践中不需要。

我的问题是关于嵌套 URL 方案（可能很深），以及如何表达特定的应用层协议，该协议可以运行在一个或多个其他传输之上，而不是原生传输。

例如，如果我正在制作“收费”服务，并且我设置了一个 GUI 桌面应用程序来处理 chargen://example.com:19/，这非常简单。但是如果我想支持一个可以在 https 之上运行的 Chargen 版本，我需要表达出来。我还希望能够单击超链接并让适当的应用程序处理程序负责该协议。所以按照 git 的例子，它可能看起来像 chargen+https://example.com/ 或者可能是 chargen://https://example.com/

在现实世界中，我最近使用了一项服务，该服务提供已发布的日历供订阅，并共享一个类似于 webcal://host.example.com/calendar/xyz 的链接。不幸的是，这并没有携带足够的信息来指示资源是 HTTP 还是 HTTPS。 （当然应该是 HTTPS，但我的意思是寻求阐明分层协议的能力。

因此，总结一下我的实际问题，我正在寻找能够清楚明确地指定如何解决通过多层协议提供的服务的标准或广泛采用的做法。

Answer 1

我刚刚遇到IANA's list of URI schemes，看来a+b:... 风格确实有一个既定的先例。这对我来说已经足够了。