webfinger - LRDD 发现和 Webfinger 之间有什么区别？

Question

所以我一直在努力了解 网指 (RFC7033) 并偶然发现 Web 主机元数据 (RFC6415)。据我所知，它们都是 RFC，并且以几乎相同的方式解决相同的问题。

因此，如果我想通过 URI 查找有关某人或某物的信息，我可以做两件事:

WebFinger 建议我导航到 /.well-known/webfinger?resource=...

Host-Meta 建议我看看 /.well-known/host-meta返回 JRD 或 XRD 类似 <link rel="lrdd" template="http://example.com/lrdd?uri={uri}">

Webfinger 只需少一次查找，并鼓励使用 JRD。为什么我不能创建一个 host-meta模板看起来像 http://example.com/.well-known/webfinger?resource={uri}并同时做这两件事(尽管是多余的)？

我缺少的两者之间有什么重要区别吗？我应该更喜欢一个吗？

Answer 1

RFC 7033 的作者在这里。

WebFinger 多年来一直在进行中，并在此期间经历了许多变化。 RFC 6415 是首次尝试标准化 WebFinger 的概念，其中包括主机元和 LRDD。使用 RFC 6415 的发现过程很复杂，因为需要执行两个查询，然后合并来自每个查询的信息以创建一组结果链接关系。此外，已经有一段时间转向 JSON。 WebFinger 使用了 XML，但 RFC 6415 附录 A 引入了 JSON 编码。人们希望这是唯一的编码。

与 RFC 6415 的原始作者和 WebFinger 社区中的其他人合作，我们在 IETF 中的一个小组致力于简化流程，将 JSON 作为内容编码，确保解决方案是安全的(仅限 HTTPS)，并获得就用于查询用户帐户信息(“acct”URI)的 URI 方案达成一致。

因此，在 RFC 7033 中，我们有一个安全、简单、单查询的发现机制，其工作原理基本如下:

$ wfinger paulej@packetizer.com

这个“wfinger”客户端要做的是找到域“packetizer.com”，然后发出以下查询(使用 curl 只是为了使示例清晰):

$ curl https://packetizer.com/.well-known/webfinger?resource=acct%3Apaulej%40packetizer.com

请注意，任何 URI 方案仍然可以与 WebFinger 一起使用——这个概念并没有丢失。因此，与最初的 WebFinger 一样，可以查询有关网页(例如 www.packetizer.com)或其他类型内容的信息。这是一个例子:

$ curl https://packetizer.com/.well-known/webfinger?resource=http%3A%2F%2Fwww.packetizer.com

这将返回关于页面“ http://www.packetizer.com”的链接关系和其他元数据。