1

我很惊讶

域 example.com的支持JMAP的电子邮件主机应该发布 SRV 记录 _jmaps._tcp.example.com，它提供主机名和端口（通常是端口 443）。

身份验证 URL 是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。

例如，知名 URI 的注册机构接受这一点的可能性有多大？还是更有可能保留为非标准的东西，比如虚构的 URI 方案？

4

1 回答 1

0

这个想法几乎肯定来自 CalDav，它已经在知名 URI 的注册表中。RFC 6532定义了 DNS SRV 以及 DNS TXT 和众所周知的 URI。所以JMAP的提议是完全有根据的。

对 URL 进行身份验证可能听起来很奇怪，但这在 CalDav 中也是合理的。我认为它有助于在多个服务器之间分片用户。

IMO 这不是使用 SRV 的好方法。另一方面，JMAP 专门考虑不使用 SRV 的客户端。有人推测 CalDav 的使用是出于类似的原因。

很奇怪，大概以网络为中心的实现无法发现完整的 URI（即，如果它们使用自动配置协议）。

我认为您必须记住，这些方法是从用户电子邮件地址开始的。神圣的 Web 体系结构使用HTTP URI 来处理所有事情……好吧，假设它对 URI 没什么好说的mailto:。DNS 必须是弥合从域到 URI 的差距的“正确”方式。但是在一个以网络为中心的世界里，你不一定知道如何解析 DNS，或者只知道如何查找 IP 来与 HTTP 对话？会有一些妥协。

于 2016-03-24T14:38:35.493 回答