Internet Engineering Task Force (IETF) E. Hammer-Lahav, Ed.
Request for Comments: 6415 B. Cook
Category: Standards Track October 2011
ISSN: 2070-1721
Internet Engineering Task Force (IETF) E. Hammer-Lahav, Ed.
Request for Comments: 6415 B. Cook
Category: Standards Track October 2011
ISSN: 2070-1721
Web Host Metadata
Web主机元数据
Abstract
摘要
This specification describes a method for locating host metadata as well as information about individual resources controlled by the host.
本规范描述了一种定位主机元数据的方法以及有关主机控制的单个资源的信息。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6415.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6415.
Copyright Notice
版权公告
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2011 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction ....................................................2
1.1. Example ....................................................3
1.1.1. Processing Resource-Specific Information ............4
1.2. Notational Conventions .....................................5
2. Obtaining host-meta Documents ...................................6
3. The host-meta Document ..........................................6
3.1. XML Document Format ........................................7
3.1.1. The "Link" Element ..................................7
4. Processing host-meta Documents ..................................8
4.1. Host-Wide Information ......................................9
4.2. Resource-Specific Information ..............................9
5. Security Considerations ........................................10
6. IANA Considerations ............................................11
6.1. The "host-meta" Well-Known URI ............................11
6.2. The "host-meta.json" Well-Known URI .......................11
6.3. The "lrdd" Relation Type ..................................11
Appendix A. JRD Document Format ...................................12
Appendix B. Acknowledgments .......................................15
Normative References ..............................................15
1. Introduction ....................................................2
1.1. Example ....................................................3
1.1.1. Processing Resource-Specific Information ............4
1.2. Notational Conventions .....................................5
2. Obtaining host-meta Documents ...................................6
3. The host-meta Document ..........................................6
3.1. XML Document Format ........................................7
3.1.1. The "Link" Element ..................................7
4. Processing host-meta Documents ..................................8
4.1. Host-Wide Information ......................................9
4.2. Resource-Specific Information ..............................9
5. Security Considerations ........................................10
6. IANA Considerations ............................................11
6.1. The "host-meta" Well-Known URI ............................11
6.2. The "host-meta.json" Well-Known URI .......................11
6.3. The "lrdd" Relation Type ..................................11
Appendix A. JRD Document Format ...................................12
Appendix B. Acknowledgments .......................................15
Normative References ..............................................15
Web-based protocols often require the discovery of host policy or metadata, where "host" is not a single resource but the entity controlling the collection of resources identified by Uniform Resource Identifiers (URIs) with a common URI host [RFC3986], which can be served by one or more servers.
基于Web的协议通常需要发现主机策略或元数据，其中“主机”不是单个资源，而是控制由统一资源标识符（URI）标识的资源集合的实体，具有公共URI主机[RFC3986]，可由一个或多个服务器提供服务。
While web protocols have a wide range of metadata needs, they often use metadata that is concise, has simple syntax requirements, and can benefit from storing their metadata in a common location used by other related protocols.
虽然web协议有广泛的元数据需求，但它们通常使用简洁的元数据，具有简单的语法要求，并且可以受益于将元数据存储在其他相关协议使用的公共位置。
Because there is no URI or representation available to describe a host, many of the methods used for associating per-resource metadata (such as HTTP headers) are not available. This often leads to the overloading of the root HTTP resource (e.g., 'http://example.com/') with host metadata that is not specific or relevant to the root resource itself.
由于没有URI或表示法可用于描述主机，因此用于关联每资源元数据（如HTTP头）的许多方法都不可用。这通常会导致根HTTP资源过载（例如'http://example.com/“”的主机元数据，该元数据与根资源本身不特定或不相关。
This document defines a lightweight metadata document format for describing hosts (thus the name "host-meta"), intended for use by web-based protocols. This document also registers the well-known URI suffix "host-meta" in the Well-Known URI Registry established by [RFC5785].
本文档定义了一种轻量级元数据文档格式，用于描述主机（因此称为“主机元”），供基于web的协议使用。本文档还将众所周知的URI后缀“host meta”注册到由[RFC5785]建立的众所周知的URI注册表中。
In addition, there are times when a host-wide scope for policy or metadata is too coarse-grained. host-meta provides two mechanisms for providing resource-specific information:
此外，有时策略或元数据的主机范围过于粗粒度。主机元提供两种机制来提供特定于资源的信息：
o Link Templates - links using a URI template instead of a fixed target URI, providing a way to define generic rules for generating resource-specific links by applying the individual resource URI to the template.
o 链接模板-使用URI模板而不是固定目标URI的链接，通过将单个资源URI应用于模板，提供了一种定义生成资源特定链接的通用规则的方法。
o Link-based Resource Descriptor Documents (LRDD, pronounced 'lard') - descriptor documents providing resource-specific information, typically information that cannot be expressed using link templates. LRDD documents are linked to resources or host-meta documents using link templates with the "lrdd" relation type.
o 基于链接的资源描述符文档（LRDD，发音为“lard”）—提供资源特定信息的描述符文档，通常是无法使用链接模板表达的信息。LRDD文档使用具有“LRDD”关系类型的链接模板链接到资源或宿主元文档。
The following is a simple host-meta document including both host-wide and resource-specific information for the 'example.com' host:
以下是一个简单的主机元文档，包括“example.com”主机的主机范围和资源特定信息：
<?xml version='1.0' encoding='UTF-8'?>
<XRD xmlns='http://docs.oasis-open.org/ns/xri/xrd-1.0'>
<?xml version='1.0' encoding='UTF-8'?>
<XRD xmlns='http://docs.oasis-open.org/ns/xri/xrd-1.0'>
<!-- Host-Wide Information -->
<!-- Host-Wide Information -->
<Property type='http://protocol.example.net/version'>1.0</Property>
<Property type='http://protocol.example.net/version'>1.0</Property>
<Link rel='copyright'
href='http://example.com/copyright' />
<Link rel='copyright'
href='http://example.com/copyright' />
<!-- Resource-specific Information -->
<!-- Resource-specific Information -->
<Link rel='hub'
template='http://example.com/hub' />
<Link rel='hub'
template='http://example.com/hub' />
<Link rel='lrdd'
type='application/xrd+xml'
template='http://example.com/lrdd?uri={uri}' />
<Link rel='lrdd'
type='application/xrd+xml'
template='http://example.com/lrdd?uri={uri}' />
<Link rel='author'
template='http://example.com/author?q={uri}' />
<Link rel='author'
template='http://example.com/author?q={uri}' />
</XRD>
</XRD>
The host-wide information that applies to the host in its entirety provided by the document includes:
本文件提供的适用于整个主机的主机范围信息包括：
o An "http://protocol.example.net/version" host property with a value of "1.0".
o "http://protocol.example.net/version值为“1.0”的主机属性。
o A link to the host's copyright policy ("copyright").
o 指向主机版权政策（“版权”）的链接。
The resource-specific information provided by the document includes:
本文件提供的资源特定信息包括：
o A link template for receiving real-time updates ("hub") about individual resources. Since the template does not include a template variable, the target URI is identical for all resources.
o 用于接收有关单个资源的实时更新（“hub”）的链接模板。由于模板不包含模板变量，因此所有资源的目标URI都是相同的。
o A LRDD document link template ("lrdd") for obtaining additional resource-specific information contained in a separate document for each individual resource.
o LRDD文档链接模板（“LRDD”），用于获取每个单独资源的单独文档中包含的额外资源特定信息。
o A link template for finding information about the author of individual resources ("author").
o 用于查找个人资源作者（“作者”）信息的链接模板。
When looking for information about an individual resource -- for example, the resource identified by 'http://example.com/xy' -- the resource URI is applied to the templates found, producing the following links:
查找有关单个资源的信息时—例如，由http://example.com/xy“--资源URI应用于找到的模板，生成以下链接：
<Link rel='hub'
href='http://example.com/hub' />
<Link rel='hub'
href='http://example.com/hub' />
<Link rel='lrdd'
type='application/xrd+xml'
href='http://example.com/lrdd?uri=http%3A%2F%2Fexample.com%2Fxy' />
<Link rel='lrdd'
type='application/xrd+xml'
href='http://example.com/lrdd?uri=http%3A%2F%2Fexample.com%2Fxy' />
<Link rel='author'
href='http://example.com/author?q=http%3A%2F%2Fexample.com%2Fxy' />
<Link rel='author'
href='http://example.com/author?q=http%3A%2F%2Fexample.com%2Fxy' />
The LRDD document for 'http://example.com/xy' (obtained via an HTTP "GET" request):
“的LRDD文件”http://example.com/xy'（通过HTTP“GET”请求获得）：
<?xml version='1.0' encoding='UTF-8'?>
<XRD xmlns='http://docs.oasis-open.org/ns/xri/xrd-1.0'>
<?xml version='1.0' encoding='UTF-8'?>
<XRD xmlns='http://docs.oasis-open.org/ns/xri/xrd-1.0'>
<Subject>http://example.com/xy</Subject>
<Subject>http://example.com/xy</Subject>
<Property type='http://spec.example.net/color'>red</Property>
<Property type='http://spec.example.net/color'>red</Property>
<Link rel='hub'
href='http://example.com/another/hub' />
<Link rel='hub'
href='http://example.com/another/hub' />
<Link rel='author'
href='http://example.com/john' />
</XRD>
<Link rel='author'
href='http://example.com/john' />
</XRD>
Together, the information available about the individual resource (presented as an Extensible Resource Descriptor (XRD) document for illustration purposes) is:
总之，关于单个资源的可用信息（作为可扩展资源描述符（XRD）文档呈现，用于说明）如下：
<?xml version='1.0' encoding='UTF-8'?>
<XRD xmlns='http://docs.oasis-open.org/ns/xri/xrd-1.0'>
<?xml version='1.0' encoding='UTF-8'?>
<XRD xmlns='http://docs.oasis-open.org/ns/xri/xrd-1.0'>
<Subject>http://example.com/xy</Subject>
<Subject>http://example.com/xy</Subject>
<Property type='http://spec.example.net/color'>red</Property>
<Property type='http://spec.example.net/color'>red</Property>
<Link rel='hub'
href='http://example.com/hub' />
<Link rel='hub'
href='http://example.com/hub' />
<Link rel='hub'
href='http://example.com/another/hub' />
<Link rel='hub'
href='http://example.com/another/hub' />
<Link rel='author'
href='http://example.com/john' />
<Link rel='author'
href='http://example.com/john' />
<Link rel='author'
href='http://example.com/author?q=http%3A%2F%2Fexample.com%2Fxy' />
<Link rel='author'
href='http://example.com/author?q=http%3A%2F%2Fexample.com%2Fxy' />
</XRD>
</XRD>
Note that the order of links matters and is based on their original order in the host-meta and LRDD documents. For example, the "hub" link obtained from the host-meta link template has a higher priority than the link found in the LRDD document because the host-meta link appears before the "lrdd" link.
请注意，链接的顺序很重要，并且基于它们在主机meta和LRDD文档中的原始顺序。例如，从主机元链接模板获得的“集线器”链接的优先级高于在LRDD文档中找到的链接，因为主机元链接出现在“LRDD”链接之前。
On the other hand, the "author" link found in the LRDD document has a higher priority than the link found in the host-meta document because it appears after the "lrdd" link.
另一方面，在LRDD文档中找到的“author”链接比在宿主元文档中找到的链接具有更高的优先级，因为它出现在“LRDD”链接之后。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“建议”、“不建议”、“可”和“可选”应按照[RFC2119]中的说明进行解释。
This document uses the Augmented Backus-Naur Form (ABNF) notation of [RFC5234]. Additionally, the following rules are included from [RFC3986]: reserved, unreserved, and pct-encoded.
本文件使用[RFC5234]的扩充巴科斯诺尔形式（ABNF）符号。此外，[RFC3986]还包括以下规则：保留、非保留和pct编码。
The client obtains the host-meta document for a given host by sending an HTTP [RFC2616] or an HTTPS [RFC2818] GET request to the host for the "/.well-known/host-meta" path, using the default ports defined for each protocol (e.g., port 80 for HTTP and port 443 for HTTPS). The scope and meaning of host-meta documents obtained via other protocols or ports is undefined.
客户机通过向主机发送HTTP[RFC2616]或HTTPS[RFC2818]GET请求，使用为每个协议定义的默认端口（例如，HTTP的端口80和HTTPS的端口443），获取给定主机的主机元文档。通过其他协议或端口获取的主机元文档的范围和含义尚未定义。
The server MUST support at least one protocol but MAY support both. If both protocols are supported, they MUST produce the same document.
服务器必须至少支持一种协议，但可以同时支持两种协议。如果两个协议都受支持，则它们必须生成相同的文档。
The decision as to which protocol is used to obtain the host-meta document has significant security ramifications, as described in Section 5.
如第5节所述，关于使用哪个协议来获取主机元文档的决定具有重大的安全影响。
For example, the following request is used to obtain the host-meta document for the 'example.com' host:
例如，以下请求用于获取“example.com”主机的主机元文档：
GET /.well-known/host-meta HTTP/1.1
Host: example.com
GET /.well-known/host-meta HTTP/1.1
Host: example.com
If the server response indicates that the host-meta resource is located elsewhere (a 301, 302, or 307 response status code), the client SHOULD try to obtain the resource from the location provided in the response. This means that the host-meta document for one host MAY be retrieved from another host. Likewise, if the resource is not available or does not exist (e.g., a 404 or 410 response status code), the client SHOULD infer that metadata is not available via this mechanism.
如果服务器响应指示主机元资源位于其他位置（301、302或307响应状态代码），则客户端应尝试从响应中提供的位置获取资源。这意味着可以从另一台主机检索一台主机的主机元文档。类似地，如果资源不可用或不存在（例如，404或410响应状态代码），则客户机应通过该机制推断元数据不可用。
The host-meta document SHOULD be served with the "application/xrd+xml" media type.
主机元文档应使用“application/xrd+xml”媒体类型提供。
The host-meta document uses the XRD 1.0 document format as defined by [OASIS.XRD-1.0], which provides a simple and extensible XML-based schema for describing resources. This specification defines additional processing rules needed to describe hosts. Documents MAY include any elements included in the XRD 1.0 schema that are not explicitly excluded by this specification.
主机元文档使用[OASIS.XRD-1.0]定义的XRD 1.0文档格式，它提供了一个简单且可扩展的基于XML的模式来描述资源。本规范定义了描述主机所需的其他处理规则。文件可能包括XRD 1.0模式中未明确排除在本规范之外的任何元素。
The server MAY offer alternative representations of any XRD document it serves (host-meta, LRDD, or other XRD-based documents). The client MAY request a particular representation using the HTTP "Accept" request header field. If no "Accept" request header field is included with the request, or if the client requests an "application/xrd+xml" representation, the server MUST respond using the REQUIRED XRD 1.0 XML representation described in Section 3.1.
服务器可以提供其服务的任何XRD文档的替代表示（主机元数据、LRDD或其他基于XRD的文档）。客户端可以使用HTTP“Accept”请求头字段请求特定的表示。如果请求中不包含“接受”请求标头字段，或者如果客户端请求“应用程序/xrd+xml”表示，则服务器必须使用第3.1节中描述的所需xrd 1.0 xml表示进行响应。
Applications using the host-meta document MAY require the server to provide a specific alternative representation in addition to the XRD 1.0 XML representation when explicitly requested by the client.
当客户端明确请求时，使用主机元文档的应用程序可能要求服务器提供XRD 1.0 XML表示之外的特定替代表示。
A JavaScript Object Notation (JSON) Resource Descriptor, known as JRD, is described in Appendix A. It is RECOMMENDED that servers offer the JRD representation in addition to the XRD representation.
JavaScript对象表示法（JSON）资源描述符（称为JRD）在附录A中进行了描述。建议服务器除了提供XRD表示外，还提供JRD表示。
The host-meta document root MUST be an "XRD" element. The document SHOULD NOT include a "Subject" element, as at this time no URI is available to identify hosts. The use of the "Alias" element in host-meta is undefined and NOT RECOMMENDED.
主机元文档根必须是“XRD”元素。文档不应包含“Subject”元素，因为此时没有可用于标识主机的URI。主机元中的“Alias”元素未定义，不建议使用。
The subject (or "context IRI", as defined by [RFC5988]) of the XRD "Property" and "Link" elements is the host described by the host-meta document. However, the subject of "Link" elements with a "template" attribute is the individual resource whose URI is applied to the link template, as described in Section 3.1.1.
XRD“属性”和“链接”元素的主题（或[RFC5988]定义的“上下文IRI”）是主机元文档描述的主机。但是，具有“模板”属性的“链接”元素的主题是其URI应用于链接模板的单个资源，如第3.1.1节所述。
The XRD "Link" element, when used with the "href" attribute, conveys a link relation between the host described by the document and a common target URI.
XRD“Link”元素与“href”属性一起使用时，表示文档描述的主机与公共目标URI之间的链接关系。
For example, the following link declares a common copyright license for the entire scope:
例如，以下链接声明了整个范围的通用版权许可证：
<Link rel='copyright' href='http://example.com/copyright' />
<Link rel='copyright' href='http://example.com/copyright' />
However, a "Link" element with a "template" attribute conveys a relation whose context is an individual resource within the host-meta document scope, and whose target is constructed by applying the context resource URI to the template. The template string MAY contain a URI string without any variables to represent a resource-level relation that is identical for every individual resource.
但是，具有“template”属性的“Link”元素传递的关系的上下文是主机元文档范围内的单个资源，其目标是通过将上下文资源URI应用于模板来构建的。模板字符串可能包含一个URI字符串，该字符串不包含任何变量，以表示每个单独资源相同的资源级别关系。
For example, a blog with multiple authors can provide information about each article's author by providing an endpoint with a parameter set to the URI of each article. Each article has a unique author, but all share the same pattern of where that information is located:
例如，一个有多个作者的博客可以通过为每篇文章的URI设置参数来提供一个端点，从而提供关于每篇文章作者的信息。每篇文章都有一个唯一的作者，但所有文章都共享该信息所在的相同模式：
<Link rel='author'
template='http://example.com/author?article={uri}' />
<Link rel='author'
template='http://example.com/author?article={uri}' />
This specification defines a simple template syntax for URI transformation. A template is a string containing brace-enclosed ("{}") variable names marking the parts of the string that are to be substituted by the corresponding variable values.
该规范为URI转换定义了一个简单的模板语法。模板是一个字符串，其中包含大括号括起来的（{}）变量名，用于标记字符串中要由相应变量值替换的部分。
Before substituting template variables, values MUST be encoded using UTF-8, and any character other than unreserved (as defined by [RFC3986]) MUST be percent-encoded per [RFC3986].
在替换模板变量之前，必须使用UTF-8对值进行编码，并且除未保留字符（如[RFC3986]所定义）之外的任何字符必须按照[RFC3986]进行百分比编码。
This specification defines a single variable -- "uri" -- as the entire context resource URI. Protocols MAY define additional relation-specific variables and syntax rules, but SHOULD only do so for protocol-specific relation types, and MUST NOT change the meaning of the "uri" variable. If a client is unable to successfully process a template (e.g., unknown variable names, unknown or incompatible syntax), the parent "Link" element SHOULD be ignored.
该规范将单个变量“uri”定义为整个上下文资源uri。协议可以定义其他特定于关系的变量和语法规则，但只应针对特定于协议的关系类型这样做，并且不得更改“uri”变量的含义。如果客户端无法成功处理模板（例如，未知变量名、未知或不兼容语法），则应忽略父“Link”元素。
The template syntax ABNF follows:
模板语法ABNF如下所示：
URI-Template = *( uri-char / variable )
variable = "{" var-name "}"
uri-char = ( reserved / unreserved / pct-encoded )
var-name = %x75.72.69 / ( 1*var-char ) ; "uri" or other names
var-char = ALPHA / DIGIT / "." / "_"
URI-Template = *( uri-char / variable )
variable = "{" var-name "}"
uri-char = ( reserved / unreserved / pct-encoded )
var-name = %x75.72.69 / ( 1*var-char ) ; "uri" or other names
var-char = ALPHA / DIGIT / "." / "_"
For example:
例如：
Input: http://example.com/r?f=1
Template: http://example.org/?q={uri}
Output: http://example.org/?q=http%3A%2F%2Fexample.com%2Fr%3Ff%3D1
Input: http://example.com/r?f=1
Template: http://example.org/?q={uri}
Output: http://example.org/?q=http%3A%2F%2Fexample.com%2Fr%3Ff%3D1
Once the host-meta document has been obtained, the client processes its content based on the type of information desired: host-wide or resource-specific.
一旦获得主机元文档，客户机将根据所需的信息类型处理其内容：主机范围的或特定于资源的。
Clients usually look for a link with a specific relation type or other attributes. In such cases, the client does not need to process the entire host-meta document and all linked LRDD documents, but instead process the various documents in their prescribed order until the desired information is found.
客户机通常查找具有特定关系类型或其他属性的链接。在这种情况下，客户机不需要处理整个主机元文档和所有链接的LRDD文档，而是按照规定的顺序处理各种文档，直到找到所需的信息。
Protocols using host-meta must indicate whether the information they seek is host-wide or resource-specific -- for example, "obtain the first host-meta resource-specific link using the 'author' relation type". If both types are used for the same purpose (e.g., first look for resource-specific, then look for host-wide), the protocol must specify the processing order.
使用主机元的协议必须指明它们所寻找的信息是主机范围的还是特定于资源的——例如，“使用‘author’关系类型获取第一个特定于主机元资源的链接”。如果两种类型用于相同的目的（例如，首先查找特定资源，然后查找主机范围），则协议必须指定处理顺序。
When looking for host-wide information, the client MUST ignore any "Link" elements with a "template" attribute, as well as any link using the "lrdd" relation type. All other elements are scoped as host-wide.
在查找主机范围的信息时，客户端必须忽略任何具有“template”属性的“Link”元素，以及任何使用“lrdd”关系类型的链接。所有其他元素的作用域均为主机范围。
Unlike host-wide information, which is contained solely within the host-meta document, resource-specific information is obtained from host-meta link templates, as well as from linked LRDD documents.
与仅包含在主机元文档中的主机范围的信息不同，特定于资源的信息是从主机元链接模板以及链接的LRDD文档中获得的。
When looking for resource-specific information, the client constructs a resource descriptor by collecting and processing all the host-meta link templates. For each link template:
在查找特定于资源的信息时，客户机通过收集和处理所有主机元链接模板来构造资源描述符。对于每个链接模板：
1. The client applies the URI of the desired resource to the template, producing a resource-specific link.
1. 客户端将所需资源的URI应用于模板，生成特定于资源的链接。
2. If the link's relation type is other than "lrdd", the client adds the link to the resource descriptor in order.
2. 如果链接的关系类型不是“lrdd”，则客户端将按顺序将链接添加到资源描述符中。
3. If the link's relation type is "lrdd":
3. 如果链接的关系类型为“lrdd”：
3.1. The client obtains the LRDD document by following the scheme-specific rules for the LRDD document URI. If the document URI scheme is "http" or "https", the document is obtained via an HTTP "GET" request to the identified URI. If the HTTP response status code is 301, 302, or 307, the client MUST follow the redirection response and repeat the request with the provided location.
3.1. 客户机通过遵循LRDD文档URI的方案特定规则来获取LRDD文档。如果文档URI方案是“http”或“https”，则通过对标识的URI的http“GET”请求获取文档。如果HTTP响应状态代码为301、302或307，则客户端必须遵循重定向响应并使用提供的位置重复请求。
3.2. The client adds any links found in the LRDD document to the resource descriptor in order, except for any link using the "lrdd" relation type (processing is limited to a single level of inclusion). When adding links, the client SHOULD retain any extension attributes and child elements if present (e.g., <Property> or <Title> elements).
3.2. 客户机将LRDD文档中找到的所有链接按顺序添加到资源描述符中，但使用“LRDD”关系类型的链接除外（处理仅限于单个包含级别）。添加链接时，客户端应保留所有扩展属性和子元素（如<Property>或<Title>元素）。
3.3. The client adds any resource properties found in the LRDD document to the resource descriptor in order (e.g., <Alias> or <Property> child elements of the LRDD document <XRD> root element).
3.3. 客户端将在LRDD文档中找到的任何资源属性按顺序添加到资源描述符中（例如，LRDD文档的<Alias>或<Property>子元素<XRD>根元素）。
The host-meta document is designed to be used by other applications explicitly "opting-in" to use the facility. Therefore, any such application MUST review the specific security implications of using host-meta documents. By itself, this specification does not provide any protections or guarantees that any given host-meta document is under the control of the appropriate entity as required by each application.
主机元文档旨在供其他明确“选择”使用该工具的应用程序使用。因此，任何这样的应用程序都必须检查使用主机元文档的特定安全影响。就其本身而言，本规范不提供任何保护或保证，任何给定的主机元文档都处于每个应用程序所需的适当实体的控制之下。
The metadata returned by the host-meta resource is presumed to be under the control of the appropriate authority and representative of all the resources described by it. If this resource is compromised or otherwise under the control of another party, it may represent a risk to the security of the server and data served by it, depending on the applications using it.
主机元资源返回的元数据被认为是在适当的权威机构的控制下，并代表它所描述的所有资源。如果此资源受到破坏或在另一方的控制下，则可能会对服务器及其所服务的数据的安全造成风险，具体取决于使用它的应用程序。
Applications utilizing the host-meta document where the authenticity of the information is necessary MUST require the use of the HTTPS protocol and MUST NOT produce a host-meta document using other means. In addition, such applications MUST require that any redirection leading to the retrieval of a host-meta document also utilize the HTTPS protocol.
在需要信息真实性的情况下，使用主机元文档的应用程序必须使用HTTPS协议，并且不得使用其他方式生成主机元文档。此外，此类应用程序必须要求导致检索主机元文档的任何重定向也使用HTTPS协议。
Since the host-meta document is authoritative for the entire host, not just the authority (combination of scheme, host, and port) of the host-meta document server, applications MUST ensure that using a host-meta document for another URI authority does not represent a potential security exploit.
由于主机元文档对整个主机具有权威性，而不仅仅是主机元文档服务器的权限（方案、主机和端口的组合），因此应用程序必须确保将主机元文档用于另一个URI权限不代表潜在的安全漏洞。
Protocols using host-meta templates must evaluate the construction of their templates as well as any protocol-specific variables or syntax to ensure that the templates cannot be abused by an attacker. For example, a client can be tricked into following a malicious link due to a poorly constructed template that produces unexpected results when its variable values contain unexpected characters.
使用主机元模板的协议必须评估其模板的构造以及任何特定于协议的变量或语法，以确保模板不会被攻击者滥用。例如，当客户端的变量值包含意外字符时，由于构造不良的模板会产生意外结果，因此客户端可能会被诱骗跟踪恶意链接。
This specification registers the "host-meta" well-known URI in the Well-Known URI Registry as defined by [RFC5785].
本规范在[RFC5785]定义的众所周知的URI注册表中注册“主机元”众所周知的URI。
URI suffix: host-meta
URI后缀：主机元
Change controller: IETF
更改控制器：IETF
Specification document(s): RFC 6415
规范文件：RFC 6415
Related information: The "host-meta" documents obtained from the same host using the HTTP and HTTPS protocols (using default ports) MUST be identical.
相关信息：使用HTTP和HTTPS协议（使用默认端口）从同一主机获取的“主机元”文档必须相同。
This specification registers the "host-meta.json" well-known URI in the Well-Known URI Registry as defined by [RFC5785].
本规范在[RFC5785]定义的众所周知的URI注册表中注册“host meta.json”众所周知的URI。
URI suffix: host-meta.json
URI后缀：host-meta.json
Change controller: IETF
更改控制器：IETF
Specification document(s): RFC 6415
规范文件：RFC 6415
Related information: The "host-meta.json" documents obtained from the same host using the HTTP and HTTPS protocols (using default ports) MUST be identical.
相关信息：使用HTTP和HTTPS协议（使用默认端口）从同一主机获取的“host meta.json”文档必须相同。
This specification registers the "lrdd" relation type in the Link Relation Type Registry defined by [RFC5988]:
本规范在[RFC5988]定义的链接关系类型注册表中注册“lrdd”关系类型：
Relation Name: lrdd
关系名称：lrdd
Description: Refers to further information about the link's context, expressed as a LRDD ("Link-based Resource Descriptor Document") resource. See RFC 6415 for information about processing this relation type in host-meta documents. When used elsewhere, it refers to additional links and other metadata. Multiple instances indicate additional LRDD resources. LRDD resources MUST have an "application/xrd+xml" representation, and MAY have others.
描述：指有关链接上下文的更多信息，表示为LRDD（“基于链接的资源描述符文档”）资源。有关在主机元文档中处理此关系类型的信息，请参阅RFC 6415。在其他地方使用时，它指的是附加链接和其他元数据。多个实例表示额外的LRDD资源。LRDD资源必须具有“应用程序/xrd+xml”表示形式，并且可能具有其他表示形式。
Reference: RFC 6415
参考：RFC6415
The JRD document format -- a general-purpose XRD 1.0 representation -- uses the JavaScript Object Notation (JSON) format defined in [RFC4627]. JRD uses the same elements and processing rules described in Section 3.1. The JRD format is designed to include the same base functionality provided by the XML format, with the exception of extensibility, as extensibility is beyond the scope of this specification.
JRD文档格式——一种通用XRD1.0表示法——使用[RFC4627]中定义的JavaScript对象表示法（JSON）格式。JRD使用第3.1节中描述的相同元素和处理规则。JRD格式被设计为包含与XML格式相同的基本功能，但可扩展性除外，因为可扩展性超出了本规范的范围。
The client MAY request a JRD representation using the HTTP "Accept" request header field with a value of "application/json". The server MUST include the HTTP "Content-Type" response header field with a value of "application/json". Any other "Content-Type" value (or lack thereof) indicates that the server does not support the JRD format.
客户端可以使用值为“application/json”的HTTP“Accept”请求头字段请求JRD表示。服务器必须包含值为“application/json”的HTTP“Content Type”响应头字段。任何其他“内容类型”值（或缺少该值）表示服务器不支持JRD格式。
Alternatively, the client MAY request a JRD representation by requesting the "host-meta.json" well-known document, by making a GET request for "/.well-known/host-meta.json", following the same process used for "/.well-known/host-meta". If the server does not support serving a JRD representation at this location, the server MUST respond with an HTTP 404 (Not Found) status code.
或者，客户机可以通过请求“host meta.json”众所周知的文档，通过对“/.well-known/host meta.json”发出GET请求，请求JRD表示，遵循与“/.well-known/host-meta”相同的过程。如果服务器不支持在此位置提供JRD表示，则服务器必须使用HTTP 404（未找到）状态代码进行响应。
XRD elements are serialized into a JSON object as follows:
XRD元素序列化为JSON对象，如下所示：
o The XML document declaration and "XRD" element are discarded.
o XML文档声明和“XRD”元素被丢弃。
o The "Subject" element is included as a name/value pair with the name 'subject', and value included as a string.
o “Subject”元素包含为名称为“Subject”的名称/值对，值包含为字符串。
o The "Expires" element is included as a name/value pair with the name 'expires', and value included as a string.
o “Expires”元素包含为名称为“Expires”的名称/值对，值包含为字符串。
o "Alias" elements are included as a single name/value pair with the name 'aliases', and value a string array containing the values of each element in order.
o “Alias”元素包含为一个名称/值对，名称为“Alias”，值为按顺序包含每个元素值的字符串数组。
o "Property" elements are included as a single name/value pair with the name 'properties', and value an object with each element included as a name/value pair with the value of the "type" attribute as name, and element value included as a string value. The values of properties with empty values (i.e., using the REQUIRED "xsi:nil='true'" attribute) are included as null. If more than one "Property" element is present with the same "type" attribute, only the last instance is included.
o “Property”元素作为名称为“properties”的单个名称/值对包含，每个元素作为名称/值对包含，每个元素的值作为“type”属性的值作为名称，元素值作为字符串值包含。具有空值（即使用所需的“xsi:nil='true'”属性）的属性的值包含为null。如果存在多个具有相同“type”属性的“Property”元素，则只包括最后一个实例。
o "Link" elements are included as a single name/value pair with the name 'links', and value an array with each element included as an object. Each attribute is included as a name/value pair with the attribute name as name, and value included as a string.
o “Link”元素作为名称为“links”的单个名称/值对包含，并为数组赋值，每个元素作为对象包含。每个属性作为名称/值对包含，属性名称作为名称，值作为字符串包含。
o "Link" child "Property" elements are included using the same method as XRD-level "Property" elements using a name/value pair inside the link object.
o “链接”子“属性”元素使用与XRD级别的“属性”元素相同的方法包括在链接对象中使用名称/值对。
o "Link" child "Title" elements are included as a single object with the name 'titles', and value an object with each element included as a name/value pair with the value of the "xml:lang" attribute as name, and element value included as a string value. The names of elements without an "xml:lang" attribute are added with the name 'default'. If more than one "Title" element is present with the same (or no) "xml:lang" attribute, only the last instance is included.
o “Link”子“Title”元素作为一个名为“titles”的对象包含，每个元素的值作为名称/值对包含，属性“xml:lang”的值作为名称，元素值作为字符串值包含。没有“xml:lang”属性的元素的名称将添加为“default”。如果存在多个具有相同（或没有）“xml:lang”属性的“Title”元素，则只包含最后一个实例。
o The conversion of any other element is left undefined.
o 任何其他元素的转换都未定义。
For example, the following XRD document...
例如，下面的XRD文档。。。
<?xml version='1.0' encoding='UTF-8'?>
<XRD xmlns='http://docs.oasis-open.org/ns/xri/xrd-1.0'
xmlns:xsi='http://www.w3.org/2001/XMLSchema-instance'>
<?xml version='1.0' encoding='UTF-8'?>
<XRD xmlns='http://docs.oasis-open.org/ns/xri/xrd-1.0'
xmlns:xsi='http://www.w3.org/2001/XMLSchema-instance'>
<Subject>http://blog.example.com/article/id/314</Subject>
<Expires>2010-01-30T09:30:00Z</Expires>
<Subject>http://blog.example.com/article/id/314</Subject>
<Expires>2010-01-30T09:30:00Z</Expires>
<Alias>http://blog.example.com/cool_new_thing</Alias>
<Alias>http://blog.example.com/steve/article/7</Alias>
<Alias>http://blog.example.com/cool_new_thing</Alias>
<Alias>http://blog.example.com/steve/article/7</Alias>
<Property type='http://blgx.example.net/ns/version'>1.2</Property>
<Property type='http://blgx.example.net/ns/version'>1.3</Property>
<Property type='http://blgx.example.net/ns/ext' xsi:nil='true' />
<Property type='http://blgx.example.net/ns/version'>1.2</Property>
<Property type='http://blgx.example.net/ns/version'>1.3</Property>
<Property type='http://blgx.example.net/ns/ext' xsi:nil='true' />
<Link rel='author' type='text/html'
href='http://blog.example.com/author/steve'>
<Title>About the Author</Title>
<Title xml:lang='en-us'>Author Information</Title>
<Property type='http://example.com/role'>editor</Property>
</Link>
<Link rel='author' type='text/html'
href='http://blog.example.com/author/steve'>
<Title>About the Author</Title>
<Title xml:lang='en-us'>Author Information</Title>
<Property type='http://example.com/role'>editor</Property>
</Link>
<Link rel='author' href='http://example.com/author/john'>
<Title>The other guy</Title>
<Title>The other author</Title>
</Link>
<Link rel='author' href='http://example.com/author/john'>
<Title>The other guy</Title>
<Title>The other author</Title>
</Link>
<Link rel='copyright'
template='http://example.com/copyright?id={uri}' />
</XRD>
<Link rel='copyright'
template='http://example.com/copyright?id={uri}' />
</XRD>
...is represented by the following JRD document:
…由以下JRD文档表示：
{ "subject":"http://blog.example.com/article/id/314", "expires":"2010-01-30T09:30:00Z",
{“主题”：http://blog.example.com/article/id/314，“到期”：“2010-01-30T09:30:00Z”，
"aliases":[ "http://blog.example.com/cool_new_thing", "http://blog.example.com/steve/article/7"],
“别名”：[“http://blog.example.com/cool_new_thing", "http://blog.example.com/steve/article/7"],
"properties":{ "http://blgx.example.net/ns/version":"1.3", "http://blgx.example.net/ns/ext":null },
“属性”：{”http://blgx.example.net/ns/version":"1.3", "http://blgx.example.net/ns/ext“：null}，
"links":[
{
"rel":"author",
"type":"text/html",
"href":"http://blog.example.com/author/steve",
"titles":{
"default":"About the Author",
"en-us":"Author Information"
},
"properties":{
"http://example.com/role":"editor"
}
},
{
"rel":"author",
"href":"http://example.com/author/john",
"titles":{
"default":"The other author"
}
},
{
"rel":"copyright",
"template":"http://example.com/copyright?id={uri}"
}
]
}
"links":[
{
"rel":"author",
"type":"text/html",
"href":"http://blog.example.com/author/steve",
"titles":{
"default":"About the Author",
"en-us":"Author Information"
},
"properties":{
"http://example.com/role":"editor"
}
},
{
"rel":"author",
"href":"http://example.com/author/john",
"titles":{
"default":"The other author"
}
},
{
"rel":"copyright",
"template":"http://example.com/copyright?id={uri}"
}
]
}
Note that the "Subject" and "Alias" elements are NOT RECOMMENDED in the context of host-meta documents, and are included in the example for completeness only.
请注意，“Subject”和“Alias”元素不建议在宿主元文档的上下文中使用，并且仅出于完整性考虑而包含在示例中。
The authors would like to acknowledge the contributions of everyone who provided feedback and use cases for this specification -- in particular, Dirk Balfanz, DeWitt Clinton, Eve Maler, Breno de Medeiros, Brad Fitzpatrick, James Manger, Will Norris, Mark Nottingham, John Panzer, Drummond Reed, and Peter Saint-Andre.
作者要感谢为本规范提供反馈和用例的每个人的贡献，特别是Dirk Balfanz、DeWitt Clinton、Eve Maler、Breno de Medeiros、Brad Fitzpatrick、James Manger、Will Norris、Mark Nottingham、John Panzer、Drummond Reed和Peter Saint Andre。
Normative References
规范性引用文件
[OASIS.XRD-1.0] Hammer-Lahav, E., Ed., and W. Norris, Ed., "Extensible Resource Descriptor (XRD) Version 1.0", November 2010, <http://docs.oasis-open.org/xri/xrd/v1.0/xrd-1.0.html>.
[OASIS.XRD-1.0]Hammer Lahav，E.，Ed.和W.Norris，Ed.，“可扩展资源描述符（XRD）版本1.0”，2010年11月<http://docs.oasis-open.org/xri/xrd/v1.0/xrd-1.0.html>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC2616]菲尔丁，R.，盖蒂斯，J.，莫卧儿，J.，弗莱斯蒂克，H.，马斯特，L.，利奇，P.，和T.伯纳斯李，“超文本传输协议——HTTP/1.1”，RFC 2616，1999年6月。
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
[RFC2818]Rescorla，E.，“TLS上的HTTP”，RFC2818，2000年5月。
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005.
[RFC3986]Berners Lee，T.，Fielding，R.，和L.Masinter，“统一资源标识符（URI）：通用语法”，STD 66，RFC 3986，2005年1月。
[RFC4627] Crockford, D., "The application/json Media Type for JavaScript Object Notation (JSON)", RFC 4627, July 2006.
[RFC4627]Crockford，D.，“JavaScript对象表示法（json）的应用程序/json媒体类型”，RFC4627，2006年7月。
[RFC5234] Crocker, D., Ed., and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC5234]Crocker，D.，Ed.，和P.Overell，“语法规范的扩充BNF:ABNF”，STD 68，RFC 5234，2008年1月。
[RFC5785] Nottingham, M. and E. Hammer-Lahav, "Defining Well-Known Uniform Resource Identifiers (URIs)", RFC 5785, April 2010.
[RFC5785]诺丁汉，M.和E.Hammer Lahav，“定义众所周知的统一资源标识符（URI）”，RFC 5785，2010年4月。
[RFC5988] Nottingham, M., "Web Linking", RFC 5988, October 2010.
[RFC5988]诺丁汉，M.，“网络链接”，RFC 5988，2010年10月。
Authors' Addresses
作者地址
Eran Hammer-Lahav (editor)
埃兰·哈默·拉哈夫（编辑）
EMail: eran@hueniverse.com
URI: http://hueniverse.com
EMail: eran@hueniverse.com
URI: http://hueniverse.com
Blaine Cook
布雷恩·库克
EMail: romeda@gmail.com
URI: http://romeda.org
EMail: romeda@gmail.com
URI: http://romeda.org