Internet Engineering Task Force (IETF) Z. Shelby
Request for Comments: 6690 Sensinode
Category: Standards Track August 2012
ISSN: 2070-1721
Internet Engineering Task Force (IETF) Z. Shelby
Request for Comments: 6690 Sensinode
Category: Standards Track August 2012
ISSN: 2070-1721
Constrained RESTful Environments (CoRE) Link Format
受限RESTful环境（核心）链接格式
Abstract
摘要
This specification defines Web Linking using a link format for use by constrained web servers to describe hosted resources, their attributes, and other relationships between links. Based on the HTTP Link Header field defined in RFC 5988, the Constrained RESTful Environments (CoRE) Link Format is carried as a payload and is assigned an Internet media type. "RESTful" refers to the Representational State Transfer (REST) architecture. A well-known URI is defined as a default entry point for requesting the links hosted by a server.
此规范使用链接格式定义Web链接，供受约束的Web服务器使用，以描述托管资源、其属性以及链接之间的其他关系。基于RFC 5988中定义的HTTP链接头字段，受限RESTful环境（CoRE）链接格式作为有效负载携带，并分配给Internet媒体类型。“RESTful”指的是代表性状态转移（Representational State Transfer，REST）体系结构。众所周知的URI被定义为请求服务器托管的链接的默认入口点。
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/rfc6690.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6690.
Copyright Notice
版权公告
Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2012 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 ....................................................3
1.1. Web Linking in CoRE ........................................3
1.2. Use Cases ..................................................4
1.2.1. Discovery ...........................................4
1.2.2. Resource Collections ................................5
1.2.3. Resource Directory ..................................5
1.3. Terminology ................................................6
2. Link Format .....................................................6
2.1. Target and Context URIs ....................................8
2.2. Link Relations .............................................8
2.3. Use of Anchors .............................................9
3. CoRE Link Attributes ............................................9
3.1. Resource Type 'rt' Attribute ...............................9
3.2. Interface Description 'if' Attribute ......................10
3.3. Maximum Size Estimate 'sz' Attribute ......................10
4. Well-Known Interface ...........................................10
4.1. Query Filtering ...........................................12
5. Examples .......................................................13
6. Security Considerations ........................................15
7. IANA Considerations ............................................16
7.1. Well-Known 'core' URI .....................................16
7.2. New 'hosts' Relation Type .................................16
7.3. New 'link-format' Internet Media Type .....................17
7.4. Constrained RESTful Environments (CoRE) Parameters
Registry ..................................................18
8. Acknowledgments ................................................19
9. References .....................................................20
9.1. Normative References ......................................20
9.2. Informative References ....................................20
1. Introduction ....................................................3
1.1. Web Linking in CoRE ........................................3
1.2. Use Cases ..................................................4
1.2.1. Discovery ...........................................4
1.2.2. Resource Collections ................................5
1.2.3. Resource Directory ..................................5
1.3. Terminology ................................................6
2. Link Format .....................................................6
2.1. Target and Context URIs ....................................8
2.2. Link Relations .............................................8
2.3. Use of Anchors .............................................9
3. CoRE Link Attributes ............................................9
3.1. Resource Type 'rt' Attribute ...............................9
3.2. Interface Description 'if' Attribute ......................10
3.3. Maximum Size Estimate 'sz' Attribute ......................10
4. Well-Known Interface ...........................................10
4.1. Query Filtering ...........................................12
5. Examples .......................................................13
6. Security Considerations ........................................15
7. IANA Considerations ............................................16
7.1. Well-Known 'core' URI .....................................16
7.2. New 'hosts' Relation Type .................................16
7.3. New 'link-format' Internet Media Type .....................17
7.4. Constrained RESTful Environments (CoRE) Parameters
Registry ..................................................18
8. Acknowledgments ................................................19
9. References .....................................................20
9.1. Normative References ......................................20
9.2. Informative References ....................................20
The Constrained RESTful Environments (CoRE) realizes the Representational State Transfer (REST) architecture [REST] in a suitable form for the most constrained nodes (e.g., 8-bit microcontrollers with limited memory) and networks (e.g., IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs) [RFC4919]). CoRE is aimed at Machine-to-Machine (M2M) applications such as smart energy and building automation.
受约束的RESTful环境（CoRE）以最受约束的节点（例如，内存有限的8位微控制器）和网络（例如，低功率无线个人区域网络（6LoWPANs）上的IPv6）[RFC4919]）的适当形式实现代表性状态传输（REST）架构[REST]。CoRE的目标是机器对机器（M2M）应用，如智能能源和楼宇自动化。
The discovery of resources hosted by a constrained server is very important in machine-to-machine applications where there are no humans in the loop and static interfaces result in fragility. The discovery of resources provided by an HTTP [RFC2616] web server is typically called "Web Discovery" and the description of relations between resources is called "Web Linking" [RFC5988]. In the present specification, we refer to the discovery of resources hosted by a constrained web server, their attributes, and other resource relations as CoRE Resource Discovery.
在机器对机器的应用程序中，发现受约束服务器承载的资源非常重要，因为在这种应用程序中，循环中没有人，静态接口会导致脆弱性。HTTP[RFC2616]web服务器提供的资源发现通常称为“web发现”，资源之间关系的描述称为“web链接”[RFC5988]。在本规范中，我们将受约束的web服务器承载的资源、其属性和其他资源关系的发现称为核心资源发现。
The main function of such a discovery mechanism is to provide Universal Resource Identifiers (URIs, called links) for the resources hosted by the server, complemented by attributes about those resources and possible further link relations. In CoRE, this collection of links is carried as a resource of its own (as opposed to HTTP headers delivered with a specific resource). This document specifies a link format for use in CoRE Resource Discovery by extending the HTTP Link Header format [RFC5988] to describe these link descriptions. The CoRE Link Format is carried as a payload and is assigned an Internet media type. A well-known relative URI "/.well-known/core" is defined as a default entry point for requesting the list of links about resources hosted by a server and thus performing CoRE Resource Discovery. This specification is applicable for use with Constrained Application Protocol (CoAP) [COAP], HTTP, or any other suitable web transfer protocol. The link format can also be saved in file format.
这种发现机制的主要功能是为服务器托管的资源提供通用资源标识符（URI，称为链接），并由这些资源的属性和可能的进一步链接关系进行补充。在CoRE中，这个链接集合作为自己的资源进行传输（与使用特定资源交付的HTTP头相反）。本文档通过扩展HTTP链接头格式[RFC5988]来描述这些链接描述，从而指定用于核心资源发现的链接格式。核心链路格式作为有效负载携带，并被分配互联网媒体类型。众所周知的相对URI“/.well-known/core”被定义为一个默认入口点，用于请求关于服务器托管的资源的链接列表，从而执行核心资源发现。本规范适用于约束应用程序协议（CoAP）[CoAP]、HTTP或任何其他合适的web传输协议。链接格式也可以保存为文件格式。
Technically, the CoRE Link Format is a serialization of a typed link as specified in [RFC5988], used to describe relationships between resources, so-called "Web Linking". In this specification, Web Linking is extended with specific constrained M2M attributes; links are carried as a message payload rather than in an HTTP Link Header field, and a default interface is defined to discover resources hosted by a server. This specification also defines a new relation
从技术上讲，核心链接格式是[RFC5988]中指定的类型链接的序列化，用于描述资源之间的关系，即所谓的“Web链接”。在本规范中，使用特定的受约束M2M属性扩展Web链接；链接作为消息负载而不是HTTP链接头字段进行，并且定义了一个默认接口来发现服务器托管的资源。本规范还定义了一种新的关系
type "hosts" (from the verb "to host"), which indicates that the resource is hosted by the server from which the link document was requested.
键入“hosts”（来自动词“to host”），表示资源由请求链接文档的服务器托管。
In HTTP, the Link Header can be used to carry link information about a resource along with an HTTP response. This works well for the typical use case for a web server and browser, where further information about a particular resource is useful after accessing it. In CoRE, the main use case for Web Linking is the discovery of which resources a server hosts in the first place. Although some resources may have further links associated with them, this is expected to be an exception. For that reason, the CoRE Link Format serialization is carried as a resource representation of a well-known URI. The CoRE Link Format does reuse the format of the HTTP Link Header serialization defined in [RFC5988].
在HTTP中，链接头可用于携带有关资源的链接信息以及HTTP响应。这适用于web服务器和浏览器的典型用例，在这种情况下，访问特定资源后，有关该资源的进一步信息非常有用。在CoRE中，Web链接的主要用例是发现服务器首先承载哪些资源。尽管某些资源可能有更多与之相关联的链接，但这可能是一个例外。因此，核心链接格式序列化作为已知URI的资源表示进行。核心链接格式确实重用了[RFC5988]中定义的HTTP链接头序列化格式。
Typical use cases for Web Linking on today's web include, e.g., describing the author of a web page or describing relations between web pages (next chapter, previous chapter, etc.). Web Linking can also be applied to M2M applications, where typed links are used to assist a machine client in finding and understanding how to use resources on a server. In this section a few use cases are described for how the CoRE Link Format could be used in M2M applications. For further technical examples, see Section 5. As there is a large range of M2M applications, these use cases are purposely generic. This specification assumes that different deployments or application domains will define the appropriate REST Interface Descriptions along with Resource Types to make discovery meaningful.
当今Web上Web链接的典型用例包括，例如，描述Web页面的作者或描述Web页面之间的关系（下一章、上一章等）。Web链接也可以应用于M2M应用程序，其中类型化链接用于帮助机器客户端查找和理解如何使用服务器上的资源。本节介绍了在M2M应用程序中如何使用核心链路格式的几个用例。有关更多技术示例，请参见第5节。由于M2M应用程序的范围很广，因此这些用例是特意通用的。本规范假设不同的部署或应用程序域将定义适当的REST接口描述以及资源类型，以使发现有意义。
In M2M applications, for example, home or building automation, there is a need for local clients and servers to find and interact with each other without human intervention. The CoRE Link Format can be used by servers in such environments to enable Resource Discovery of the resources hosted by the server.
在M2M应用程序中，例如家庭或楼宇自动化，需要本地客户端和服务器在无需人工干预的情况下相互查找和交互。核心链接格式可由此类环境中的服务器使用，以实现对服务器承载的资源的资源发现。
Resource Discovery can be performed either unicast or multicast. When a server's IP address is already known, either a priori or resolved via the Domain Name System (DNS) [RFC1034][RFC1035], unicast discovery is performed in order to locate the entry point to the resource of interest. In this specification, this is performed using a GET to "/.well-known/core" on the server, which returns a payload in the CoRE Link Format. A client would then match the appropriate Resource Type, Interface Description, and possible media type
资源发现可以执行单播或多播。当服务器的IP地址已知时，无论是先验的还是通过域名系统（DNS）[RFC1034][RFC1035]解析的，都会执行单播发现，以便找到感兴趣的资源的入口点。在本规范中，这是使用服务器上的GET to“/.well-known/core”来执行的，它以核心链接格式返回有效负载。然后，客户机将匹配适当的资源类型、接口描述和可能的媒体类型
[RFC2045] for its application. These attributes may also be included in the query string in order to filter the number of links returned in a response.
[RFC2045]用于其应用。这些属性也可以包含在查询字符串中，以便过滤响应中返回的链接数。
Multicast Resource Discovery is useful when a client needs to locate a resource within a limited scope, and that scope supports IP multicast. A GET request to the appropriate multicast address is made for "/.well-known/core". In order to limit the number and size of responses, a query string is recommended with the known attributes. Typically, a resource would be discovered based on its Resource Type and/or Interface Description, along with possible application-specific attributes.
当客户端需要在有限的作用域内定位资源并且该作用域支持IP多播时，多播资源发现非常有用。为“/.well-known/core”发出对适当多播地址的GET请求。为了限制响应的数量和大小，建议使用具有已知属性的查询字符串。通常，将根据资源类型和/或接口描述以及可能的特定于应用程序的属性来发现资源。
RESTful designs of M2M interfaces often make use of collections of resources. For example, an index of temperature sensors on a data collection node or a list of alarms on a home security controller. The CoRE Link Format can be used to make it possible to find the entry point to a collection and traverse its members. The entry point of a collection would always be included in "/.well-known/core" to enable its discovery. The members of the collection can be defined either through the Interface Description of the resource along with a parameter resource for the size of the collection or by using the link format to describe each resource in the collection. These links could be located under "/.well-known/core" or hosted, for example, in the root resource of the collection.
M2M接口的RESTful设计通常使用资源集合。例如，数据采集节点上的温度传感器索引或家庭安全控制器上的报警列表。核心链接格式可用于找到集合的入口点并遍历其成员。集合的入口点将始终包含在“/.well-known/core”中，以实现其发现。集合的成员可以通过资源的接口描述以及集合大小的参数resource来定义，也可以使用链接格式来描述集合中的每个资源。这些链接可以位于“/.well-known/core”下，或者托管在集合的根资源中。
In many deployment scenarios, for example, constrained networks with sleeping servers or large M2M deployments with bandwidth limited access networks, it makes sense to deploy resource directory entities that store links to resources stored on other servers. Think of this as a limited search engine for constrained M2M resources.
在许多部署场景中，例如，具有休眠服务器的受限网络或具有带宽受限访问网络的大型M2M部署，部署存储到其他服务器上存储的资源的链接的资源目录实体是有意义的。可以将其视为受限M2M资源的有限搜索引擎。
The CoRE Link Format can be used by a server to register resources with a resource directory or to allow a resource directory to poll for resources. Resource registration can be achieved by having each server POST their resources to "/.well-known/core" on the resource directory. This, in turn, adds links to the resource directory under an appropriate resource. These links can then be discovered by any client by making a request to a resource directory lookup interface.
服务器可以使用核心链接格式向资源目录注册资源，或允许资源目录轮询资源。可以通过让每个服务器将其资源发布到资源目录上的“/.well-known/core”来实现资源注册。这又会将链接添加到相应资源下的资源目录。然后，任何客户端都可以通过向资源目录查找接口发出请求来发现这些链接。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this specification are to be interpreted as described in [RFC2119].
本规范中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
This specification makes use of the Augmented Backus-Naur Form (ABNF) [RFC5234] notation, including the core rules defined in Appendix B of that document.
本规范使用了扩展的巴科斯诺尔表（ABNF）[RFC5234]符号，包括该文件附录B中定义的核心规则。
This specification requires readers to be familiar with all the terms and concepts that are discussed in [RFC5988] and [RFC6454]. In addition, this specification makes use of the following terminology:
本规范要求读者熟悉[RFC5988]和[RFC6454]中讨论的所有术语和概念。此外，本规范使用了以下术语：
Web Linking A framework for indicating the relationships between web resources.
Web链接用于指示Web资源之间关系的框架。
Link Also called "typed links" in [RFC5988]. A link is a typed connection between two resources identified by URI and is made up of a context URI, a link relation type, a target URI, and optional target attributes.
链接在[RFC5988]中也称为“类型链接”。链接是由URI标识的两个资源之间的类型化连接，由上下文URI、链接关系类型、目标URI和可选的目标属性组成。
Link Format A particular serialization of typed links.
链接格式键入链接的特定序列化。
CoRE Link Format A particular serialization of typed links based on the HTTP Link Header field serialization defined in Section 5 of [RFC5988] but carried as a resource representation with a media type.
核心链接格式基于[RFC5988]第5节中定义的HTTP链接头字段序列化的特定类型链接序列化，但作为媒体类型的资源表示进行。
Attribute Properly called "Target Attribute" in [RFC5988]. A key/value pair that describes the link or its target.
在[RFC5988]中正确称为“目标属性”的属性。描述链接或其目标的键/值对。
CoRE Resource Discovery When a client discovers the list of resources hosted by a server, their attributes, and other link relations by accessing "/.well-known/core".
核心资源发现当客户端通过访问“/.well-known/CoRE”发现服务器托管的资源列表、它们的属性和其他链接关系时。
The CoRE Link Format extends the HTTP Link Header field specified in [RFC5988]. The format does not require special XML or binary parsing, is fairly compact, and is extensible -- all important characteristics for CoRE. It should be noted that this link format is just one serialization of typed links defined in [RFC5988]; others
核心链接格式扩展了[RFC5988]中指定的HTTP链接头字段。该格式不需要特殊的XML或二进制解析，相当紧凑，并且是可扩展的——所有这些都是CoRE的重要特征。应该注意的是，此链接格式只是[RFC5988]中定义的类型化链接的一种序列化；其他
include HTML links, Atom feed links [RFC4287], or HTTP Link Header fields. It is expected that resources discovered in the CoRE Link Format may also be made available in alternative formats on the greater Internet. The CoRE Link Format is only expected to be supported in constrained networks and M2M systems.
包括HTML链接、Atom提要链接[RFC4287]或HTTP链接头字段。预计以核心链接格式发现的资源也可以在更大的互联网上以其他格式提供。核心链路格式预计仅在受限网络和M2M系统中受支持。
Section 5 of [RFC5988] did not require an Internet media type for the defined link format, as it was defined to be carried in an HTTP header. This specification thus defines the Internet media type 'application/link-format' for the CoRE Link Format (see Section 7.3). Whereas the HTTP Link Header field depends on [RFC2616] for its encoding, the CoRE Link Format is encoded as UTF-8 [RFC3629]. A decoder of the format is not expected to validate UTF-8 encoding (but is not prohibited from doing so) and doesn't need to perform any UTF-8 normalization. UTF-8 data can be compared bitwise, which allows values to contain UTF-8 data without any added complexity for constrained nodes.
[RFC5988]的第5节不要求定义链接格式的Internet媒体类型，因为它被定义为在HTTP头中携带。因此，本规范为核心链接格式定义了互联网媒体类型“应用程序/链接格式”（见第7.3节）。HTTP链路头字段的编码依赖于[RFC2616]，而核心链路格式编码为UTF-8[RFC3629]。该格式的解码器不需要验证UTF-8编码（但不禁止这样做），也不需要执行任何UTF-8规范化。UTF-8数据可以按位进行比较，这允许值包含UTF-8数据，而不会增加受约束节点的复杂性。
The CoRE Link Format is equivalent to the [RFC5988] link format; however, the ABNF in the present specification is repeated with improvements to be compliant with [RFC5234] and includes new link parameters. The link parameter "href" is reserved for use as a query parameter for filtering in this specification (see Section 4.1) and MUST NOT be defined as a link parameter. As in [RFC5988], multiple link descriptions are separated by commas. Note that commas can also occur in quoted strings and URIs but do not end a description. In order to convert an HTTP Link Header field to this link format, first the "Link:" HTTP header is removed, any linear whitespace (LWS) is removed, the header value is converted to UTF-8, and any percent-encodings are decoded.
核心链路格式等同于[RFC5988]链路格式；然而，重复本规范中的ABNF，并进行改进以符合[RFC5234]，并包括新的链路参数。链接参数“href”保留用作本规范中过滤的查询参数（参见第4.1节），不得定义为链接参数。与[RFC5988]一样，多个链路描述用逗号分隔。请注意，逗号也可以出现在带引号的字符串和URI中，但不会结束描述。为了将HTTP链接头字段转换为此链接格式，首先删除“Link:”HTTP头，删除任何线性空白（LWS），将头值转换为UTF-8，并解码任何百分比编码。
Link = link-value-list
link-value-list = [ link-value *[ "," link-value ]]
link-value = "<" URI-Reference ">" *( ";" link-param )
link-param = ( ( "rel" "=" relation-types )
/ ( "anchor" "=" DQUOTE URI-Reference DQUOTE )
/ ( "rev" "=" relation-types )
/ ( "hreflang" "=" Language-Tag )
/ ( "media" "=" ( MediaDesc
/ ( DQUOTE MediaDesc DQUOTE ) ) )
/ ( "title" "=" quoted-string )
/ ( "title*" "=" ext-value )
/ ( "type" "=" ( media-type / quoted-mt ) )
/ ( "rt" "=" relation-types )
/ ( "if" "=" relation-types )
/ ( "sz" "=" cardinal )
/ ( link-extension ) )
link-extension = ( parmname [ "=" ( ptoken / quoted-string ) ] )
Link = link-value-list
link-value-list = [ link-value *[ "," link-value ]]
link-value = "<" URI-Reference ">" *( ";" link-param )
link-param = ( ( "rel" "=" relation-types )
/ ( "anchor" "=" DQUOTE URI-Reference DQUOTE )
/ ( "rev" "=" relation-types )
/ ( "hreflang" "=" Language-Tag )
/ ( "media" "=" ( MediaDesc
/ ( DQUOTE MediaDesc DQUOTE ) ) )
/ ( "title" "=" quoted-string )
/ ( "title*" "=" ext-value )
/ ( "type" "=" ( media-type / quoted-mt ) )
/ ( "rt" "=" relation-types )
/ ( "if" "=" relation-types )
/ ( "sz" "=" cardinal )
/ ( link-extension ) )
link-extension = ( parmname [ "=" ( ptoken / quoted-string ) ] )
/ ( ext-name-star "=" ext-value )
ext-name-star = parmname "*" ; reserved for RFC-2231-profiled
; extensions. Whitespace NOT
; allowed in between.
ptoken = 1*ptokenchar
ptokenchar = "!" / "#" / "$" / "%" / "&" / "'" / "("
/ ")" / "*" / "+" / "-" / "." / "/" / DIGIT
/ ":" / "<" / "=" / ">" / "?" / "@" / ALPHA
/ "[" / "]" / "^" / "_" / "`" / "{" / "|"
/ "}" / "~"
media-type = type-name "/" subtype-name
quoted-mt = DQUOTE media-type DQUOTE
relation-types = relation-type
/ DQUOTE relation-type *( 1*SP relation-type ) DQUOTE
relation-type = reg-rel-type / ext-rel-type
reg-rel-type = LOALPHA *( LOALPHA / DIGIT / "." / "-" )
ext-rel-type = URI
cardinal = "0" / ( %x31-39 *DIGIT )
LOALPHA = %x61-7A ; a-z
quoted-string = <defined in [RFC2616]>
URI = <defined in [RFC3986]>
URI-Reference = <defined in [RFC3986]>
type-name = <defined in [RFC4288]>
subtype-name = <defined in [RFC4288]>
MediaDesc = <defined in [W3C.HTML.4.01]>
Language-Tag = <defined in [RFC5646]>
ext-value = <defined in [RFC5987]>
parmname = <defined in [RFC5987]>
/ ( ext-name-star "=" ext-value )
ext-name-star = parmname "*" ; reserved for RFC-2231-profiled
; extensions. Whitespace NOT
; allowed in between.
ptoken = 1*ptokenchar
ptokenchar = "!" / "#" / "$" / "%" / "&" / "'" / "("
/ ")" / "*" / "+" / "-" / "." / "/" / DIGIT
/ ":" / "<" / "=" / ">" / "?" / "@" / ALPHA
/ "[" / "]" / "^" / "_" / "`" / "{" / "|"
/ "}" / "~"
media-type = type-name "/" subtype-name
quoted-mt = DQUOTE media-type DQUOTE
relation-types = relation-type
/ DQUOTE relation-type *( 1*SP relation-type ) DQUOTE
relation-type = reg-rel-type / ext-rel-type
reg-rel-type = LOALPHA *( LOALPHA / DIGIT / "." / "-" )
ext-rel-type = URI
cardinal = "0" / ( %x31-39 *DIGIT )
LOALPHA = %x61-7A ; a-z
quoted-string = <defined in [RFC2616]>
URI = <defined in [RFC3986]>
URI-Reference = <defined in [RFC3986]>
type-name = <defined in [RFC4288]>
subtype-name = <defined in [RFC4288]>
MediaDesc = <defined in [W3C.HTML.4.01]>
Language-Tag = <defined in [RFC5646]>
ext-value = <defined in [RFC5987]>
parmname = <defined in [RFC5987]>
Each link conveys one target URI as a URI-reference inside angle brackets ("<>"). The context URI of a link (also called the base URI in [RFC3986]) is determined by the following rules in this specification:
每个链接传递一个目标URI作为尖括号（“<>”）内的URI引用。链接的上下文URI（在[RFC3986]中也称为基本URI）由本规范中的以下规则确定：
(a) The context URI is set to the anchor parameter, when specified.
(a) 指定时，将上下文URI设置为锚参数。
(b) Origin of the target URI, when specified.
(b) 指定时目标URI的来源。
(c) Origin of the link format resource's base URI.
(c) 链接格式资源的基本URI的来源。
Since links in the CoRE Link Format are typically used to describe resources hosted by a server, the new relation type "hosts" is assumed in the absence of the relation parameter (see Section 7.2). The "hosts" relation type (from the verb "to host") indicates that
由于核心链接格式的链接通常用于描述服务器托管的资源，因此在没有关系参数的情况下，假定使用新的关系类型“hosts”（参见第7.2节）。“hosts”关系类型（从动词“to host”）表示
the target URI is a resource hosted by the server (i.e., server hosts resource) indicated by the context URI. The target URI MUST be a relative URI of the context URI for this relation type.
目标URI是由上下文URI指示的服务器承载的资源（即服务器主机资源）。目标URI必须是此关系类型的上下文URI的相对URI。
To express other relations, links can make use of any registered relation by including the relation parameter. The context of a relation can be defined using the anchor parameter. In this way, relations between resources hosted on a server or between hosted resources and external resources can be expressed.
为了表示其他关系，链接可以通过包含关系参数来使用任何已注册的关系。可以使用锚参数定义关系的上下文。通过这种方式，可以表示托管在服务器上的资源之间或托管资源与外部资源之间的关系。
As per Section 5.2 of [RFC5988], a link description MAY include an "anchor" parameter, in which case the context is the URI included in that attribute. This is used to describe a relationship between two resources. A consuming implementation can, however, choose to ignore such links. It is not expected that all implementations will be able to derive useful information from explicitly anchored links.
根据[RFC5988]第5.2节，链接描述可能包括“锚定”参数，在这种情况下，上下文是该属性中包含的URI。这用于描述两个资源之间的关系。但是，消费实现可以选择忽略此类链接。并非所有实现都能够从显式锚定链接中获得有用的信息。
The following CoRE-specific target attributes are defined in addition to those already defined in [RFC5988]. These attributes describe information useful in accessing the target link of the relation and, in some cases, can use the syntactical form of a URI. Such a URI MAY be dereferenced (for instance, to obtain a description of the link relation), but that is not part of the protocol and MUST NOT be done automatically on link evaluation. When the values of attributes are compared, they MUST be compared as strings.
除了[RFC5988]中已经定义的属性外，还定义了以下特定于核心的目标属性。这些属性描述了在访问关系的目标链接时有用的信息，在某些情况下，可以使用URI的语法形式。这样的URI可以被取消引用（例如，为了获得链路关系的描述），但是这不是协议的一部分，并且不能在链路评估时自动完成。比较属性值时，必须将它们作为字符串进行比较。
The Resource Type 'rt' attribute is an opaque string used to assign an application-specific semantic type to a resource. One can think of this as a noun describing the resource. In the case of a temperature resource, this could be, e.g., an application-specific semantic type like "outdoor-temperature" or a URI referencing a specific concept in an ontology like "http://sweet.jpl.nasa.gov/2.0/phys.owl#Temperature". Multiple Resource Types MAY be included in the value of this parameter, each separated by a space, similar to the relation attribute. The registry for Resource Type values is defined in Section 7.4.
资源类型“rt”属性是一个不透明字符串，用于将特定于应用程序的语义类型分配给资源。你可以把它看作是一个描述资源的名词。在温度资源的情况下，这可以是，例如，特定于应用程序的语义类型，如“室外温度”，或引用本体中特定概念的URI，如“室外温度”http://sweet.jpl.nasa.gov/2.0/phys.owl#Temperature". 此参数的值中可能包含多个资源类型，每个资源类型由一个空格分隔，类似于关系属性。资源类型值的注册表在第7.4节中定义。
The Resource Type attribute is not meant to be used to assign a human-readable name to a resource. The "title" attribute defined in [RFC5988] is meant for that purpose. The Resource Type attribute MUST NOT appear more than once in a link.
资源类型属性不用于为资源分配人类可读的名称。[RFC5988]中定义的“标题”属性用于此目的。资源类型属性在链接中不能出现多次。
The Interface Description 'if' attribute is an opaque string used to provide a name or URI indicating a specific interface definition used to interact with the target resource. One can think of this as describing verbs usable on a resource. The Interface Description attribute is meant to describe the generic REST interface to interact with a resource or a set of resources. It is expected that an Interface Description will be reused by different Resource Types. For example, the Resource Types "outdoor-temperature", "dew-point", and "rel-humidity" could all be accessible using the Interface Description "http://www.example.org/myapp.wadl#sensor". Multiple Interface Descriptions MAY be included in the value of this parameter, each separated by a space, similar to the relation attribute. The registry for Interface Description values is defined in Section 7.4.
接口描述“if”属性是一个不透明字符串，用于提供一个名称或URI，指示用于与目标资源交互的特定接口定义。可以将其视为描述资源上可用的动词。Interface Description属性用于描述与一个或一组资源交互的通用REST接口。预计接口描述将被不同的资源类型重用。例如，资源类型“室外温度”、“露点”和“相对湿度”都可以通过接口说明访问”http://www.example.org/myapp.wadl#sensor". 此参数的值中可能包含多个接口描述，每个接口描述用空格分隔，类似于关系属性。接口描述值的注册表在第7.4节中定义。
The Interface Description could be, for example, the URI of a Web Application Description Language (WADL) [WADL] definition of the target resource "http://www.example.org/myapp.wadl#sensor", a URN indicating the type of interface to the resource "urn:myapp:sensor", or an application-specific name "sensor". The Interface Description attribute MUST NOT appear more than once in a link.
接口描述可以是，例如，目标资源的Web应用程序描述语言（WADL）[WADL]定义的URI“http://www.example.org/myapp.wadl#sensor，指示资源“URN:myapp:sensor”接口类型的URN，或特定于应用程序的名称“sensor”。接口描述属性在链接中不得出现多次。
The maximum size estimate attribute 'sz' gives an indication of the maximum size of the resource representation returned by performing a GET on the target URI. For links to CoAP resources, this attribute is not expected to be included for small resources that can comfortably be carried in a single Maximum Transmission Unit (MTU) but SHOULD be included for resources larger than that. The maximum size estimate attribute MUST NOT appear more than once in a link.
最大大小估计属性“sz”指示通过对目标URI执行GET返回的资源表示的最大大小。对于到CoAP资源的链路，对于可以在单个最大传输单元（MTU）中轻松携带的小型资源，不应包括此属性，但对于大于此值的资源，应包括此属性。“最大大小估计”属性在链接中不能出现多次。
Note that there is no defined upper limit to the value of the 'sz' attributes. Implementations MUST be prepared to accept large values. One implementation strategy is to convert any value larger than a reasonable size limit for this implementation to a special value "Big", which in further processing would indicate that a size value was given that was so big that it cannot be processed by this implementation.
请注意，“sz”属性的值没有定义的上限。实现必须准备好接受较大的值。一种实现策略是将大于此实现的合理大小限制的任何值转换为特殊值“大”，在进一步处理中，这将表明给定的大小值太大，以致于此实现无法处理。
Resource discovery in CoRE is accomplished through the use of a well-known resource URI that returns a list of links about resources hosted by that server and other link relations. Well-known resources
CoRE中的资源发现是通过使用一个众所周知的资源URI来完成的，该URI返回关于该服务器托管的资源的链接列表和其他链接关系。知名资源
have a path component that begins with "/.well-known/" as specified in [RFC5785]. This specification defines a new well-known resource for CoRE Resource Discovery: "/.well-known/core".
具有[RFC5785]中指定的以“/.well-known/”开头的路径组件。本规范为核心资源发现定义了一个新的已知资源：“/.well-known/CoRE”。
A server implementing this specification MUST support this resource on the default port appropriate for the protocol for the purpose of resource discovery. It is, however, up to the application which links are included and how they are organized. The resource "/.well-known/core" is meant to be used to return links to the entry points of resource interfaces on a server. More sophisticated link organization can be achieved by including links to CoRE Link Format resources located elsewhere on the server, for example, to achieve an index. In the absence of any links, a zero-length payload is returned. The resource representation of this resource MUST be the CoRE Link Format described in Section 2.
为了进行资源发现，实现此规范的服务器必须在适用于协议的默认端口上支持此资源。然而，这取决于应用程序包括哪些链接以及它们是如何组织的。资源“/.well-known/core”用于返回指向服务器上资源接口入口点的链接。更复杂的链接组织可以通过包含指向服务器上其他位置的核心链接格式资源的链接来实现，例如，实现索引。在没有任何链路的情况下，返回零长度的有效负载。此资源的资源表示形式必须是第2节中描述的核心链接格式。
The CoRE resource discovery interface supports the following interactions:
核心资源发现接口支持以下交互：
o Performing a GET on "/.well-known/core" to the default port returns a set of links available from the server (if any) in the CoRE Link Format. These links might describe resources hosted on that server or on other servers or express other kinds of link relations as described in Section 2.
o 对默认端口执行GET on“/.well-known/core”将返回一组可从服务器获得的核心链接格式的链接（如果有）。这些链接可能描述托管在该服务器或其他服务器上的资源，或者表示第2节中描述的其他类型的链接关系。
o Filtering may be performed on any of the link format attributes using a query string as specified in Section 4.1. For example, [GET /.well-known/core?rt=temperature-c] would request resources with the Resource Type temperature-c. A server is not, however, required to support filtering.
o 可以使用第4.1节中指定的查询字符串对任何链接格式属性执行过滤。例如，[GET/.well-known/core？rt=temperature-c]将请求资源类型为temperature-c的资源。但是，不需要服务器来支持筛选。
o More capable servers such as proxies could support a resource directory by requesting the resource descriptions of other end-points or allowing servers to POST requests to "/.well-known/ core". The details of such resource directory functionality is, however, out of the scope of this specification and is expected to be specified separately.
o 更强大的服务器（如代理服务器）可以通过请求其他端点的资源描述或允许服务器向“/.well-known/core”发送请求来支持资源目录。但是，此类资源目录功能的详细信息不在本规范的范围内，需要单独指定。
A server implementing this specification MAY recognize the query part of a resource discovery URI as a filter on the resources to be returned. The path and query components together should conform to the following level-4 URI Template [RFC6570]:
实现此规范的服务器可以将资源发现URI的查询部分识别为要返回的资源的筛选器。路径和查询组件一起应符合以下四级URI模板[RFC6570]：
/.well-known/core{?search*}
/.well-known/core{?search*}
where the variable "search" is a 1-element list that has a single name/value pair, where
其中变量“search”是一个具有单个名称/值对的单元素列表，其中
o name is either "href", a link-param name defined in this specification, or any other link-extension name, and
o 名称为“href”（本规范中定义的链接参数名称）或任何其他链接扩展名，以及
o value is either a Complete Value String that does not end in an "*" (%2A), or a Prefix Value String followed by an "*" (%2A).
o 值可以是不以“*”（%2A）结尾的完整值字符串，也可以是后跟“*”（%2A）的前缀值字符串。
The search name "href" refers to the URI-reference between the "<" and ">" characters of a link. Both Value Strings match a target attribute only if it exists. Value Strings are percent-decoded ([RFC3986], Section 2.1) before matching; similarly, any target attributes notated as quoted-string are interpreted as defined in Section 2.2 of [RFC2616]. After these steps, a Complete Value String matches a target attribute if it is bitwise identical. A Prefix Value String matches a target attribute if it is a bitwise prefix of the target attribute (where any string is a prefix of itself). Empty Prefix Value Strings are allowed; by the definition above, they match any target attribute that does exist. Note that relation-type target attributes can contain multiple values, and each value MUST be treated as a separate target attribute when matching.
搜索名称“href”是指链接的“<”和“>”字符之间的URI引用。两个值字符串仅在目标属性存在时才匹配该属性。值字符串在匹配前进行百分比解码（[RFC3986]，第2.1节）；类似地，任何标记为带引号字符串的目标属性均按照[RFC2616]第2.2节中的定义进行解释。在这些步骤之后，如果目标属性按位相同，则完整的值字符串将与目标属性匹配。如果前缀值字符串是目标属性的按位前缀（其中任何字符串都是其自身的前缀），则它与目标属性匹配。允许前缀值字符串为空；根据上面的定义，它们匹配任何确实存在的目标属性。请注意，关系类型的目标属性可以包含多个值，在匹配时，每个值都必须作为单独的目标属性处理。
It is not expected that very constrained nodes support filtering. Implementations not supporting filtering MUST simply ignore the query string and return the whole resource for unicast requests.
不希望非常受约束的节点支持过滤。不支持过滤的实现必须忽略查询字符串并返回单播请求的全部资源。
When using a transfer protocol like the Constrained Application Protocol (CoAP) that supports multicast requests, special care needs to be taken. A multicast request with a query string SHOULD NOT be responded to if filtering is not supported or if the filter does not match (to avoid a needless response storm). The exception is in cases where the IP stack interface is not able to indicate that the destination address was multicast.
当使用支持多播请求的传输协议（如约束应用程序协议（CoAP））时，需要特别小心。如果不支持筛选或筛选器不匹配，则不应响应带有查询字符串的多播请求（以避免不必要的响应风暴）。例外情况是IP堆栈接口无法指示目标地址是多播的。
The following are examples of valid query URIs:
以下是有效查询URI的示例：
o ?href=/foo matches a link-value that is anchored at /foo
o ?href=/foo matches a link-value that is anchored at /foo
o ?href=/foo* matches a link-value that is anchored at a URI that
starts with /foo
o ?href=/foo* matches a link-value that is anchored at a URI that
starts with /foo
o ?foo=bar matches a link-value that has a target attribute named foo with the exact value bar
o ？foo=bar将具有名为foo的目标属性的链接值与精确的值bar匹配
o ?foo=bar* matches a link-value that has a target attribute named foo, the value of which starts with bar, e.g., bar or barley
o ？foo=bar*匹配一个链接值，该链接值具有名为foo的目标属性，该属性的值以bar开头，例如bar或大麦
o ?foo=* matches a link-value that has a target attribute named foo
o ？foo=*匹配具有名为foo的目标属性的链接值
A few examples of typical link descriptions in this format follows. Multiple resource descriptions in a representation are separated by commas. Linefeeds are also included in these examples for readability. Although the following examples use CoAP response codes, the examples are applicable to HTTP as well (the corresponding response code would be 200 OK).
以下是此格式中典型链接描述的几个示例。表示中的多个资源描述用逗号分隔。为了便于阅读，这些示例中还包括换行符。尽管以下示例使用CoAP响应代码，但这些示例也适用于HTTP（相应的响应代码为200 OK）。
This example includes links to two different sensors sharing the same Interface Description. Note that the default relation type for this link format is "hosts" in links with no rel= target attribute. Thus, the links in this example tell that the Origin server from which /.well-known/core was requested (the context) hosts the resources /sensors/temp and /sensors/light (each a target).
此示例包括指向共享相同接口描述的两个不同传感器的链接。请注意，此链接格式的默认关系类型是不带rel=target属性的链接中的“hosts”。因此，本例中的链接告诉我们，请求/.well-known/core的源服务器（上下文）承载资源/sensors/temp和/sensors/light（每个都是目标）。
REQ: GET /.well-known/core
REQ: GET /.well-known/core
RES: 2.05 Content
</sensors/temp>;if="sensor",
</sensors/light>;if="sensor"
RES: 2.05 Content
</sensors/temp>;if="sensor",
</sensors/light>;if="sensor"
Without the linefeeds inserted here for readability, the format actually looks as follows.
如果没有为可读性而在此处插入换行符，格式实际上如下所示。
</sensors/temp>;if="sensor",</sensors/light>;if="sensor"
</sensors/temp>;if="sensor",</sensors/light>;if="sensor"
This example arranges link descriptions hierarchically, with the entry point including a link to a sub-resource containing links about the sensors.
本例按层次排列链接描述，入口点包括指向包含传感器链接的子资源的链接。
REQ: GET /.well-known/core
REQ: GET /.well-known/core
RES: 2.05 Content
</sensors>;ct=40
RES: 2.05 Content
</sensors>;ct=40
REQ: GET /sensors
请求：获取/获取传感器
RES: 2.05 Content
</sensors/temp>;rt="temperature-c";if="sensor",
</sensors/light>;rt="light-lux";if="sensor"
RES: 2.05 Content
</sensors/temp>;rt="temperature-c";if="sensor",
</sensors/light>;rt="light-lux";if="sensor"
An example query filter may look like:
示例查询筛选器可能如下所示：
REQ: GET /.well-known/core?rt=light-lux
REQ: GET /.well-known/core?rt=light-lux
RES: 2.05 Content
</sensors/light>;rt="light-lux";if="sensor"
RES: 2.05 Content
</sensors/light>;rt="light-lux";if="sensor"
Note that relation-type attributes like 'rt', 'if', and 'rel' can have multiple values separated by spaces. A query filter parameter can match any one of those values, as in this example:
请注意，“rt”、“if”和“rel”等关系类型属性可以有多个由空格分隔的值。查询筛选器参数可以匹配这些值中的任意一个，如本例所示：
REQ: GET /.well-known/core?rt=light-lux
REQ: GET /.well-known/core?rt=light-lux
RES: 2.05 Content
</sensors/light>;rt="light-lux core.sen-light";if="sensor"
RES: 2.05 Content
</sensors/light>;rt="light-lux core.sen-light";if="sensor"
This example shows the use of an "anchor" attribute to relate the temperature sensor resource to an external description and to an alternative URI.
此示例显示如何使用“锚定”属性将温度传感器资源与外部描述和备选URI关联。
REQ: GET /.well-known/core
REQ: GET /.well-known/core
RES: 2.05 Content
</sensors>;ct=40;title="Sensor Index",
</sensors/temp>;rt="temperature-c";if="sensor",
</sensors/light>;rt="light-lux";if="sensor",
<http://www.example.com/sensors/t123>;anchor="/sensors/temp"
;rel="describedby",
</t>;anchor="/sensors/temp";rel="alternate"
RES: 2.05 Content
</sensors>;ct=40;title="Sensor Index",
</sensors/temp>;rt="temperature-c";if="sensor",
</sensors/light>;rt="light-lux";if="sensor",
<http://www.example.com/sensors/t123>;anchor="/sensors/temp"
;rel="describedby",
</t>;anchor="/sensors/temp";rel="alternate"
If a client is interested in finding relations about a particular resource, it can perform a query on the anchor parameter:
如果客户机对查找特定资源的关系感兴趣，则可以对锚参数执行查询：
REQ: GET /.well-known/core?anchor=/sensors/temp
REQ: GET /.well-known/core?anchor=/sensors/temp
RES: 2.05 Content
<http://www.example.com/sensors/temp123>;anchor="/sensors/temp"
;rel="describedby",
</t>;anchor="/sensors/temp";rel="alternate"
RES: 2.05 Content
<http://www.example.com/sensors/temp123>;anchor="/sensors/temp"
;rel="describedby",
</t>;anchor="/sensors/temp";rel="alternate"
The following example shows a large firmware resource with a size attribute. The consumer of this link would use the 'sz' attribute to determine if the resource representation is too large and if block transfer would be required to request it. In this case, a client with only a 64 KiB flash might only support a 16-bit integer for storing the 'sz' attribute. Thus, a special flag or value should be used to indicate "Big" (larger than 64 KiB).
下面的示例显示了具有size属性的大型固件资源。此链接的使用者将使用“sz”属性来确定资源表示是否太大，以及是否需要块传输来请求它。在这种情况下，只有64 KiB闪存的客户端可能只支持16位整数来存储“sz”属性。因此，应该使用一个特殊的标志或值来表示“大”（大于64 KiB）。
REQ: GET /.well-known/core?rt=firmware
REQ: GET /.well-known/core?rt=firmware
RES: 2.05 Content
</firmware/v2.1>;rt="firmware";sz=262144
RES: 2.05 Content
</firmware/v2.1>;rt="firmware";sz=262144
This specification has the same security considerations as described in Section 7 of [RFC5988]. The "/.well-known/core" resource MAY be protected, e.g., using Datagram Transport Layer Security (DTLS) when hosted on a CoAP server as per [COAP], Section 9.1.
本规范具有与[RFC5988]第7节所述相同的安全注意事项。根据[CoAP]第9.1节，当托管在CoAP服务器上时，“/.well-known/core”资源可以受到保护，例如使用数据报传输层安全（DTLS）。
Some servers might provide resource discovery services to a mix of clients that are trusted to different levels. For example, a lighting control system might allow any client to read state variables, but only certain clients to write state (turn lights on or off). Servers that have authentication and authorization features SHOULD support authentication features of the underlying transport protocols (HTTP or DTLS/TLS) and allow servers to return different lists of links based on a client's identity and authorization. While such servers might not return all links to all requesters, not providing the link does not, by itself, control access to the relevant resource -- a bad actor could know or guess the right URIs. Servers can also lie about the resources available. If it is important for a client to only get information from a known source, then that source needs to be authenticated.
某些服务器可能会向不同级别信任的客户机组合提供资源发现服务。例如，照明控制系统可能允许任何客户端读取状态变量，但仅允许某些客户端写入状态（打开或关闭照明）。具有身份验证和授权功能的服务器应支持底层传输协议（HTTP或DTLS/TLS）的身份验证功能，并允许服务器根据客户端的身份和授权返回不同的链接列表。虽然这样的服务器可能不会将所有链接返回给所有请求者，但不提供链接本身并不能控制对相关资源的访问——一个糟糕的参与者可能知道或猜测正确的URI。服务器还可以谎报可用资源。如果客户机只从已知源获取信息很重要，那么需要对该源进行身份验证。
Multicast requests using CoAP for the well-known link-format resources could be used to perform denial of service on a constrained network. A multicast request SHOULD only be accepted if the request is sufficiently authenticated and secured using, e.g., IPsec or an appropriate object security mechanism.
使用已知链路格式资源的CoAP的多播请求可用于在受限网络上执行拒绝服务。只有在使用IPsec或适当的对象安全机制对请求进行了充分的身份验证和安全保护后，才能接受多播请求。
CoRE Link Format parsers should be aware that a link description may be cyclical, i.e., contain a link to itself. These cyclical links could be direct or indirect (i.e., through referenced link resources). Care should be taken when parsing link descriptions and accessing cyclical links.
核心链接格式解析器应该知道链接描述可能是循环的，即包含指向自身的链接。这些循环链接可以是直接的或间接的（即通过引用链接资源）。在解析链接描述和访问循环链接时应小心。
This memo registers the 'core' well-known URI in the Well-Known URIs registry as defined by [RFC5785].
此备忘录在[RFC5785]定义的知名URI注册表中注册“核心”知名URI。
URI suffix: core
URI后缀：核心
Change controller: IETF
更改控制器：IETF
Specification document(s): RFC 6690
规范文件：RFC 6690
Related information: None
相关信息：无
This memo registers the new "hosts" Web Linking relation type as per [RFC5988].
此备忘录根据[RFC5988]注册新的“主机”Web链接关系类型。
Relation Name: hosts
关系名称：主机
Description: Refers to a resource hosted by the server indicated by the link context.
描述：指由链接上下文指示的服务器承载的资源。
Reference: RFC 6690
参考：RFC 6690
Notes: This relation is used in CoRE where links are retrieved as a "/.well-known/core" resource representation and is the default relation type in the CoRE Link Format.
注意：此关系在核心中使用，其中链接作为“/.well-known/CoRE”资源表示进行检索，并且是核心链接格式中的默认关系类型。
Application Data: None
应用数据：无
This memo registers the a new Internet media type for the CoRE Link Format, 'application/link-format'.
此备忘录为核心链接格式“应用程序/链接格式”注册了新的Internet媒体类型。
Type name: application
类型名称：应用程序
Subtype name: link-format
子类型名称：链接格式
Required parameters: None
所需参数：无
Optional parameters: None
可选参数：无
Encoding considerations: Binary data (UTF-8)
编码注意事项：二进制数据（UTF-8）
Security considerations:
安全考虑：
Multicast requests using CoAP for the well-known link-format resources could be used to perform denial of service on a constrained network. A multicast request SHOULD only be accepted if the request is sufficiently authenticated and secured using, e.g., IPsec or an appropriate object security mechanism.
使用已知链路格式资源的CoAP的多播请求可用于在受限网络上执行拒绝服务。只有在使用IPsec或适当的对象安全机制对请求进行了充分的身份验证和安全保护后，才能接受多播请求。
CoRE Link Format parsers should be aware that a link description may be cyclical, i.e., contain a link to itself. These cyclical links could be direct or indirect (i.e., through referenced link resources). Care should be taken when parsing link descriptions and accessing cyclical links.
核心链接格式解析器应该知道链接描述可能是循环的，即包含指向自身的链接。这些循环链接可以是直接的或间接的（即通过引用链接资源）。在解析链接描述和访问循环链接时应小心。
Interoperability considerations: None
互操作性注意事项：无
Published specification: RFC 6690
已发布规范：RFC 6690
Applications that use this media type: CoAP server and client implementations for resource discovery and HTTP applications that use the link-format as a payload.
使用此媒体类型的应用程序：用于资源发现的CoAP服务器和客户端实现，以及使用链接格式作为有效负载的HTTP应用程序。
Additional information:
其他信息：
Magic number(s):
幻数：
File extension(s): *.wlnk
File extension(s): *.wlnk
Macintosh file type code(s):
Macintosh文件类型代码：
Intended usage: COMMON
预期用途：普通
Restrictions on usage: None
使用限制：无
Author: CoRE WG
作者：核心工作组
Change controller: IETF
更改控制器：IETF
This specification establishes a new Constrained RESTful Environments (CoRE) Parameters registry, which contains two new sub-registries of Link Target Attribute values (defined in [RFC5988]), one for Resource Type (rt=) Link Target Attribute values and the other for Interface Description (if=) Link Target Attribute values. No initial entries are defined by this specification for either sub-registry.
本规范建立了一个新的受限RESTful环境（CoRE）参数注册表，其中包含链接目标属性值的两个新子注册表（在[RFC5988]中定义），一个用于资源类型（rt=）链接目标属性值，另一个用于接口描述（if=）链接目标属性值。本规范未为任何子注册表定义初始项。
For both sub-registries, values starting with the characters "core" are registered using the IETF Review registration policy [RFC5226]. All other values are registered using the Specification Required policy, which requires review by a designated expert appointed by the IESG or their delegate.
对于这两个子注册表，使用IETF审查注册策略[RFC5226]注册以字符“core”开头的值。所有其他值均使用规范要求的政策进行登记，该政策要求由IESG或其代表指定的专家进行审查。
The designated expert will enforce the following requirements:
指定专家将执行以下要求：
o Registration values MUST be related to the intended purpose of these attributes as described in Section 3.
o 注册值必须与第3节中描述的这些属性的预期用途相关。
o Registered values MUST conform to the ABNF reg-rel-type definition of Section 2, meaning that the value starts with a lowercase alphabetic character, followed by a sequence of lowercase alphabetic, numeric, ".", or "-" characters, and contains no white space.
o 注册值必须符合第2节的ABNF reg rel类型定义，这意味着该值以小写字母开头，后跟一系列小写字母、数字、“.”或“-”字符，并且不包含空格。
o It is recommended that the period "." character be used for dividing name segments and that the dash "-" character be used for making a segment more readable. Example Interface Description values might be "core.batch" and "core.link-batch".
o 建议使用句点“.”字符分隔名称段，并使用破折号“-”字符使段更具可读性。示例接口描述值可能是“core.batch”和“core.link batch”。
o URIs are reserved for free use as extension values for these attributes and MUST NOT be registered.
o URI保留为免费使用，作为这些属性的扩展值，不得注册。
Registration requests consist of the completed registration template below, with the reference pointing to the required specification. To allow for the allocation of values prior to publication, the designated expert may approve registration once they are satisfied that a specification will be published.
注册请求包括以下完整的注册模板，参考文件指向所需的规范。为了允许在发布前分配值，指定专家在确信规范将发布后可批准注册。
Note that Link Target Attribute Values can be registered by third parties if the Designated Expert determines that an unregistered Link Target Attribute Value is widely deployed and not likely to be registered in a timely manner.
请注意，如果指定专家确定未注册的链接目标属性值被广泛部署且不可能及时注册，则第三方可以注册链接目标属性值。
The registration template for both sub-registries is:
两个子注册中心的注册模板为：
o Attribute Value:
o 属性值：
o Description:
o 说明：
o Reference:
o 参考：
o Notes: [optional]
o 注：[可选]
Registration requests should be sent to the core-parameters@ietf.org mailing list, marked clearly in the subject line (e.g., "NEW RESOURCE TYPE - example" to register an "example" relation type or "NEW INTERFACE DESCRIPTION - example" to register an "example" Interface Description).
注册请求应发送至核心-parameters@ietf.org邮件列表，在主题行中清楚标记（例如，“新资源类型-示例”注册“示例”关系类型或“新接口描述-示例”注册“示例”接口描述）。
Within at most 14 days of the request, the Designated Expert(s) will either approve or deny the registration request, communicating this decision to the review list and IANA. Denials should include an explanation and, if applicable, suggestions as to how to make the request successful.
在申请后最多14天内，指定专家将批准或拒绝注册申请，并将此决定告知审查名单和IANA。拒绝应包括解释，以及（如适用）关于如何使请求成功的建议。
Decisions (or lack thereof) made by the Designated Expert can be first appealed to Application Area Directors (contactable using the app-ads@tools.ietf.org email address or directly by looking up their email addresses on http://www.iesg.org/ website) and, if the appellant is not satisfied with the response, to the full IESG (using the iesg@ietf.org mailing list).
指定专家做出的决定（或缺乏决定）可首先上诉至应用区域主管（可使用应用程序联系）-ads@tools.ietf.org电子邮件地址，或直接在http://www.iesg.org/ 网站），如果上诉人对答复不满意，则提交完整的IESG（使用iesg@ietf.org邮件列表）。
Special thanks to Peter Bigot, who has made a considerable number of reviews and text contributions that greatly improved the document. In particular, Peter is responsible for early improvements to the ABNF descriptions and the idea for a new 'hosts' relation type.
特别感谢Peter Bigot，他做了大量的评论和文本贡献，极大地改进了文档。特别是，Peter负责ABNF描述的早期改进和新“主机”关系类型的想法。
Thanks to Mark Nottingham and Eran Hammer-Lahav for the discussions and ideas that led to this document, and to Carsten Bormann, Martin Thomson, Alexey Melnikov, Julian Reschke, Joel Halpern, Richard Barnes, Barry Leiba, and Peter Saint-Andre for extensive comments and contributions that improved the text.
感谢马克·诺丁汉（Mark Nottingham）和埃兰·哈默·拉哈夫（Eran Hammer Lahav）的讨论和想法，感谢卡斯滕·鲍曼（Carsten Bormann）、马丁·汤姆森（Martin Thomson）、阿列克谢·梅尔尼科夫（Alexey Melnikov）、朱利安·雷什克（Julian Reschke）、乔尔·哈尔伯恩（Joel Halpern）、理查德·巴恩斯（Richard Barnes）、巴里Leiba）和。
Thanks to Michael Stuber, Richard Kelsey, Cullen Jennings, Guido Moritz, Peter Van Der Stok, Adriano Pezzuto, Lisa Dussealt, Alexey Melnikov, Gilbert Clark, Salvatore Loreto, Petri Mutka, Szymon Sasin, Robert Quattlebaum, Robert Cragie, Angelo Castellani, Tom Herbst, Ed Beroset, Gilman Tolle, Robby Simpson, Colin O'Flynn, and David Ryan for helpful comments and discussions that have shaped the document.
感谢Michael Stuber、Richard Kelsey、Cullen Jennings、Guido Moritz、Peter Van Der Stok、Adriano Pezzuto、Lisa Dusselt、Alexey Melnikov、Gilbert Clark、Salvatore Loreto、Petri Mutka、Szymon Sasin、Robert Quattlebaum、Robert Cragie、Angelo Castellani、Tom Herbst、Ed Beroset、Gilman Tolle、Robby Simpson、Colin O'Flyn、，以及David Ryan对形成该文件的有益评论和讨论。
[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月。
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003.
[RFC3629]Yergeau，F.，“UTF-8，ISO 10646的转换格式”，STD 63，RFC 3629，2003年11月。
[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月。
[RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and Registration Procedures", BCP 13, RFC 4288, December 2005.
[RFC4288]Freed，N.和J.Klensin，“介质类型规范和注册程序”，BCP 13，RFC 4288，2005年12月。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[RFC5226]Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 5226，2008年5月。
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC5234]Crocker，D.和P.Overell，“语法规范的扩充BNF:ABNF”，STD 68，RFC 5234，2008年1月。
[RFC5646] Phillips, A. and M. Davis, "Tags for Identifying Languages", BCP 47, RFC 5646, September 2009.
[RFC5646]Phillips，A.和M.Davis，“识别语言的标记”，BCP 47，RFC 5646，2009年9月。
[RFC5987] Reschke, J., "Character Set and Language Encoding for Hypertext Transfer Protocol (HTTP) Header Field Parameters", RFC 5987, August 2010.
[RFC5987]Reschke，J.，“超文本传输协议（HTTP）头字段参数的字符集和语言编码”，RFC 5987，2010年8月。
[RFC5988] Nottingham, M., "Web Linking", RFC 5988, October 2010.
[RFC5988]诺丁汉，M.，“网络链接”，RFC 5988，2010年10月。
[RFC6570] Gregorio, J., Fielding, R., Hadley, M., Nottingham, M., and D. Orchard, "URI Template", RFC 6570, March 2012.
[RFC6570]Gregorio，J.，Fielding，R.，Hadley，M.，Nottingham，M.，和D.Orchard，“URI模板”，RFC 65702012年3月。
[COAP] Shelby, Z., Hartke, K., Bormann, C., and B. Frank, "Constrained Application Protocol (CoAP)", Work in Progress, July 2012.
[COAP]Shelby，Z.，Hartke，K.，Bormann，C.，和B.Frank，“受限应用协议（COAP）”，正在进行的工作，2012年7月。
[REST] Fielding, R., "Architectural Styles and the Design of Network-based Software Architectures", 2000, <http://www.ics.uci.edu/~fielding/pubs/dissertation/ top.htm>.
[REST]Fielding，R.，“架构风格和基于网络的软件架构的设计”，2000年<http://www.ics.uci.edu/~fielding/pubs/demission/top.htm>。
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987.
[RFC1034]Mockapetris，P.，“域名-概念和设施”，STD 13，RFC 1034，1987年11月。
[RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987.
[RFC1035]Mockapetris，P.，“域名-实现和规范”，STD 13，RFC 1035，1987年11月。
[RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996.
[RFC2045]Freed，N.和N.Borenstein，“多用途Internet邮件扩展（MIME）第一部分：Internet邮件正文格式”，RFC 20451996年11月。
[RFC2231] Freed, N. and K. Moore, "MIME Parameter Value and Encoded Word Extensions: Character Sets, Languages, and Continuations", RFC 2231, November 1997.
[RFC2231]Freed，N.和K.Moore，“MIME参数值和编码字扩展：字符集、语言和连续体”，RFC 22311997年11月。
[RFC4287] Nottingham, M., Ed. and R. Sayre, Ed., "The Atom Syndication Format", RFC 4287, December 2005.
[RFC4287]诺丁汉，M.，Ed.和R.Sayre，Ed.，“原子联合格式”，RFC 4287，2005年12月。
[RFC4919] Kushalnagar, N., Montenegro, G., and C. Schumacher, "IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs): Overview, Assumptions, Problem Statement, and Goals", RFC 4919, August 2007.
[RFC4919]Kushalnagar，N.，黑山，G.，和C.Schumacher，“低功率无线个人区域网络（6LoWPANs）上的IPv6：概述，假设，问题陈述和目标”，RFC 4919，2007年8月。
[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月。
[RFC6454] Barth, A., "The Web Origin Concept", RFC 6454, December 2011.
[RFC6454]Barth，A.，“网络起源概念”，RFC 64542011年12月。
[W3C.HTML.4.01] Raggett, D., Le Hors, A., and I. Jacobs, "HTML 4.01 Specification", World Wide Web Consortium Recommendation REC-html401-19991224, December 1999, <http://www.w3.org/TR/1999/REC-html401-19991224>.
[W3C.HTML.4.01]Raggett，D.，Le Hors，A.，和I.Jacobs，“HTML 4.01规范”，万维网联盟建议REC-html401-19991224，1999年12月<http://www.w3.org/TR/1999/REC-html401-19991224>.
[WADL] Hadley, M., "Web Application Description Language (WADL)", 2009, <http://java.net/projects/wadl/sources/svn/content/ trunk/www/wadl20090202.pdf>.
[WADL]Hadley，M.，“Web应用程序描述语言（WADL）”，2009年<http://java.net/projects/wadl/sources/svn/content/ trunk/www/wadl20090202.pdf>。
Author's Address
作者地址
Zach Shelby Sensinode Kidekuja 2 Vuokatti 88600 Finland
Zach Shelby Kidekuja传感器2 Vookatti 88600芬兰
Phone: +358407796297
EMail: zach@sensinode.com
Phone: +358407796297
EMail: zach@sensinode.com