我很惊讶
一个JMAP - 支持域example.com的电子邮件主机应该发布一个SRV记录_jmaps._tcp.example.com，它提供一个主机名和端口（通常是端口443）。
身份验证网址为https://hostname/.well-known/jmap（重定向后）。
使用autoconfig.example.com或autodiscover.example.com的其他自动发现选项可能会添加到未来版本的JMAP中，以支持无法使用SRV查找的客户端。
它与众所周知的URI注册表的原始用例不匹配。像robots.txt或dnt / dnt-policy.txt这样的东西。没有它，IPP / CUPS打印工作正常，使用DNS TXT记录指定URL。如果你可以查找SRV记录，你可以同样查找TXT。自动发现协议涉及XML，显然可以包含完整的URI。
E.g。知名URI的注册表是否有机会接受这种情况？或者它更像是非标准的东西，比如伪造的URI方案？
答案 0 :(得分：0)
这个想法几乎肯定来自CalDav，它已经出现在registry众所周知的URI中。 RFC 6532定义DNS SRV以及DNS TXT和众所周知的URI。因此，JMAP的提议完全是有根据的。
对URL进行身份验证可能听起来很奇怪，但这在CalDav中也是合理的。我认为它可以帮助多个服务器之间的分片用户。
IMO这不是一个使用SRV的好方法。另一方面，JMAP专门考虑不使用SRV的客户。有人认为CalDav的使用是出于类似的原因。
似乎奇怪的是，大概以网络为中心的实现无法设法发现完整的URI（即，如果他们使用的是autoconfig协议）。
我认为您必须记住这些方法是从用户电子邮件地址开始的。使用HTTP URIs for everything的神圣Web架构......好吧，我们可以说它对mailto: URI没什么好说的。 DNS必须是弥合从域到URI的差距的“正确”方法。但是在一个以网络为中心的世界中，你不一定知道如何解析DNS，或者只知道如何查找IP来与HTTP说话？会有一些妥协。