所以我一直在努力理解 WebFinger （RFC7033）并偶然发现 Web Host Metadata （RFC6415）。据我所知，它们都是RFC并以几乎相同的方式解决了同样的问题。
因此，如果我想通过URI查找有关某人或某事物的信息，我可以做两件事：
/.well-known/webfinger?resource=... /.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}并执行这两项操作（虽然多余）？
我失踪的两个人之间有什么重要的区别吗？我应该更喜欢一个吗？
答案 0 :(得分：4)
RFC 7033的作者。
几年来，WebFinger一直在进行中，并在此期间经历了许多变化。 RFC 6415是第一次标准化WebFinger概念的尝试，其中包括host-meta和LRDD。使用RFC 6415的发现过程很复杂，因为需要执行两个查询然后合并来自每个查询的信息以创建一组结果链接关系。此外，JSON还有一段时间的举动。 WebFinger使用过XML，但RFC 6415附录A引入了JSON编码。人们希望这是唯一的编码。与WebFinger社区中的RFC 6415的原始作者和其他人一起工作，IETF中的一群人致力于简化流程，将JSON转移为内容编码，确保解决方案是安全的（仅限HTTPS） ，并获得用于查询用户帐户信息的URI方案的协议（＆＃34; acct＆＃34; URI）。
因此，对于RFC 7033，我们有一个安全，简单，一个查询的发现机制，基本上是这样的：
$ wfinger paulej@packetizer.com
这是什么＆＃34; wfinger＆＃34;客户端会做的是找到域名＆＃34; packetizer.com＆＃34;然后发出以下查询（使用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
这将返回关于页面的链接关系和其他元数据＆＃34; http://www.packetizer.com＆＃34;。
答案 1 :(得分：0)
虽然Webfinger RFC说/.well-known/webfinger?实际实现使用/.well-known/host-meta
请参阅：http://hueniverse.com/2009/09/02/implementing-webfinger/
似乎 WF已被WHM取代。