[要約] RFC 6690は、制約されたRESTful環境（CoRE）のリンク形式に関する仕様です。このRFCの目的は、IoTデバイスなどの制約のある環境でのリソースの表現と発見を容易にするための標準化を提供することです。
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環境（CoRE）リンク形式
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リンクヘッダーフィールドに基づいて、Constrained RESTful Environments（CoRE）リンクフォーマットがペイロードとして送信され、インターネットメディアタイプが割り当てられます。 「RESTful」とは、Representational State Transfer（REST）アーキテクチャを指します。ウェルノウンURIは、サーバーがホストするリンクを要求するためのデフォルトのエントリポイントとして定義されています。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはInternet Standards Trackドキュメントです。
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（Internet Engineering Task Force）の製品です。これは、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.
Copyright（c）2012 IETF Trustおよびドキュメントの作成者として特定された人物。全著作権所有。
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）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
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
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）は、Representational State Transfer（REST）アーキテクチャ[REST]を、最も制約のあるノード（たとえば、メモリが制限された8ビットマイクロコントローラー）とネットワーク（たとえば、IPv6 over Low-Power Wireless）に適した形式で実現しますパーソナルエリアネットワーク（6LoWPAN）[RFC4919]）。 CoREは、スマートエネルギーやビルディングオートメーションなどのMachine-to-Machine（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サーバーがホストするリソースの発見、それらの属性、およびその他のリソース関係をCoREリソース発見と呼びます。
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]を拡張してCoREリソースディスカバリで使用するリンクフォーマットを指定し、これらのリンクの説明を説明します。 CoREリンクフォーマットはペイロードとして伝送され、インターネットメディアタイプが割り当てられます。既知の相対URI "/.well-known/core"は、サーバーがホストするリソースに関するリンクのリストを要求し、それによってCoRE Resource Discoveryを実行するためのデフォルトのエントリポイントとして定義されます。この仕様は、制約付きアプリケーションプロトコル（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 type "hosts" (from the verb "to host"), which indicates that the resource is hosted by the server from which the link document was requested.
技術的には、CoREリンクフォーマットは、[RFC5988]で指定されている型付きリンクのシリアル化であり、リソース間の関係を記述するために使用されます。いわゆる「Webリンク」です。この仕様では、Webリンクは特定の制約付きM2M属性で拡張されています。リンクは、HTTPリンクヘッダーフィールドではなくメッセージペイロードとして伝送され、サーバーによってホストされているリソースを検出するためのデフォルトインターフェイスが定義されています。この仕様では、新しい関係タイプ「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リンクの主な使用例は、サーバーが最初にホストするリソースの発見です。一部のリソースにはさらにリンクが関連付けられている場合がありますが、これは例外であると予想されます。そのため、CoREリンク形式のシリアル化は、既知のURIのリソース表現として行われます。 CoREリンク形式は、[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アプリケーションでCoREリンクフォーマットを使用する方法について、いくつかの使用例を説明します。さらなる技術的な例については、セクション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アプリケーションでは、ローカルのクライアントとサーバーが、人間の介入なしにお互いを検出して対話する必要があります。このような環境のサーバーは、CoREリンク形式を使用して、サーバーがホストするリソースのリソース検出を有効にすることができます。
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]によって解決されている場合、対象のリソースへのエントリポイントを見つけるためにユニキャスト検出が実行されます。この仕様では、これはサーバー上の "/.well-known/core"へのGETを使用して実行され、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な設計は、多くの場合、リソースのコレクションを利用します。たとえば、データ収集ノードの温度センサーのインデックス、またはホームセキュリティコントローラーのアラームのリスト。 CoREリンク形式を使用して、コレクションへのエントリポイントを見つけ、そのメンバーをトラバースできるようにすることができます。コレクションのエントリポイントは、発見を可能にするために常に「/.well-known/core」に含まれます。コレクションのメンバーは、コレクションのサイズのパラメーターリソースと共にリソースのインターフェイスの説明を介して、またはリンク形式を使用してコレクション内の各リソースを説明することによって定義できます。これらのリンクは、「/。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.
サーバーはCoREリンク形式を使用して、リソースをリソースディレクトリに登録したり、リソースディレクトリがリソースをポーリングできるようにしたりできます。リソースの登録は、各サーバーにリソースディレクトリの「/.well-known/core」にリソースをPOSTさせることで実現できます。これにより、適切なリソースの下のリソースディレクトリへのリンクが追加されます。これらのリンクは、リソースディレクトリルックアップインターフェイスにリクエストを送信することにより、どのクライアントでも検出できます。
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].
この仕様のキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 [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.
この仕様は、そのドキュメントの付録Bで定義されているコアルールを含むAugmented Backus-Naur Form（ABNF）[RFC5234]表記を利用しています。
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で識別される2つのリソース間の型付き接続であり、コンテキスト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.
CoREリンク形式[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".
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 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.
CoREリンク形式は、[RFC5988]で指定されたHTTPリンクヘッダーフィールドを拡張します。この形式は、特別なXMLまたはバイナリ解析を必要とせず、かなりコンパクトで、拡張可能です-CoREのすべての重要な特性。このリンク形式は、[RFC5988]で定義されている型付きリンクのシリアル化の1つにすぎないことに注意してください。その他には、HTMLリンク、Atomフィードリンク[RFC4287]、またはHTTPリンクヘッダーフィールドが含まれます。 CoREリンク形式で発見されたリソースは、より大規模なインターネット上の代替形式でも利用できるようになると予想されます。 CoREリンクフォーマットは、制約されたネットワークと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では、HTTPヘッダーで伝送されるように定義されているため、定義されたリンク形式にインターネットメディアタイプを必要としませんでした。したがって、この仕様では、CoREリンク形式のインターネットメディアタイプ「application / link-format」を定義しています（セクション7.3を参照）。 HTTPリンクヘッダーフィールドのエンコードは[RFC2616]に依存しますが、CoREリンクフォーマットは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.
CoREリンクフォーマットは、[RFC5988]リンクフォーマットと同等です。ただし、本仕様のABNFは、[RFC5234]に準拠するように改善されて繰り返され、新しいリンクパラメータが含まれています。リンクパラメータ「href」は、この仕様でフィルタリングするためのクエリパラメータとして使用するために予約されており（セクション4.1を参照）、リンクパラメータとして定義してはなりません（MUST NOT）。 [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 ) ] )
/ ( 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:
各リンクは、1つのターゲットURIを山括弧（ "<>"）内のURI参照として伝達します。リンクのコンテキストURI（[RFC3986]ではベースURIとも呼ばれます）は、この仕様では次のルールによって決定されます。
(a) The context URI is set to the anchor parameter, when specified.
（a）コンテキストURIは、指定された場合、anchorパラメーターに設定されます。
(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 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.
CoREリンク形式のリンクは通常、サーバーがホストするリソースを記述するために使用されるため、関係パラメーターが存在しない場合は、新しい関係タイプ「ホスト」が想定されます（セクション7.2を参照）。 「hosts」関係タイプ（動詞「to host」から）は、ターゲット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.
他の関係を表現するために、リンクは、関係パラメーターを含めることにより、登録された関係を利用できます。関係のコンテキストは、anchorパラメータを使用して定義できます。このようにして、サーバーでホストされているリソース間の関係、またはホストされているリソースと外部リソース間の関係を表すことができます。
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です。これは、2つのリソース間の関係を記述するために使用されます。ただし、消費型の実装では、このようなリンクを無視することを選択できます。すべての実装が明示的にアンカーされたリンクから有用な情報を導出できるとは限りません。
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]ですでに定義されている属性に加えて、次のCoRE固有のターゲット属性が定義されています。これらの属性は、関係のターゲットリンクへのアクセスに役立つ情報を記述し、場合によっては、URIの構文形式を使用できます。そのようなURIは逆参照してもよい（たとえば、リンク関係の説明を取得するため）が、それはプロトコルの一部ではなく、リンク評価時に自動的に行われてはならない（MUST NOT）。属性の値が比較されるとき、それらは文字列として比較されなければなりません。
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」属性は、アプリケーション固有のセマンティックタイプをリソースに割り当てるために使用される不透明な文字列です。これは、リソースを説明する名詞と考えることができます。温度リソースの場合、これは、たとえば、「outdoor-temperature」のようなアプリケーション固有のセマンティックタイプ、または「http://sweet.jpl.nasa.gov/」のようなオントロジーの特定の概念を参照するURIになります。 2.0 / phys.owl＃Temperature」。このパラメータの値には、relation属性と同様に、それぞれがスペースで区切られた複数のリソースタイプを含めることができます。リソースタイプ値のレジストリは、セクション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.
Resource Type属性は、人間が読み取れる名前をリソースに割り当てるために使用するためのものではありません。 [RFC5988]で定義されている「title」属性は、その目的のためのものです。リソースタイプ属性は、リンクに複数回出現してはなりません。
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を提供するために使用される不透明な文字列です。これは、リソースで使用可能な動詞を説明していると考えることができます。インターフェースの説明属性は、リソースまたはリソースのセットと対話するための一般的なRESTインターフェースを説明するためのものです。インターフェイスの説明は、さまざまなリソースタイプで再利用されることが期待されています。たとえば、リソースタイプ「outdoor-temperature」、「dew-point」、および「rel-humidity」はすべて、インターフェイスの説明「http://www.example.org/myapp.wadl#sensor」を使用してアクセスできます。このパラメータの値には、relation属性と同様に、スペースで区切られた複数のインターフェイスの説明を含めることができます。 Interface Description値のレジストリは、セクション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.
インターフェースの説明は、たとえば、ターゲットリソース「http://www.example.org/myapp.wadl#sensor」のWebアプリケーション記述言語（WADL）[WADL]定義のURIであり、URNはリソース「urn：myapp：sensor」へのインターフェースのタイプ、またはアプリケーション固有の名前「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）で快適に伝送できる小さなリソースには含まれないと予想されますが、それよりも大きいリソースには含まれる必要があります（SHOULD）。最大サイズ見積もり属性は、リンク内に複数回出現してはなりません（MUST NOT）。
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」属性の値に定義された上限がないことに注意してください。大きな値を受け入れるように実装を準備する必要があります。 1つの実装戦略は、この実装の妥当なサイズ制限より大きい値を特別な値「Big」に変換することです。これは、以降の処理で、この実装では処理できないほど大きいサイズ値が指定されたことを示します。
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 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".
CoREでのリソース検出は、そのサーバーによってホストされているリソースと他のリンク関係に関するリンクのリストを返す、よく知られたリソースURIを使用して行われます。 [RFC5785]で指定されているように、既知のリソースには、「/。well-known /」で始まるパスコンポーネントがあります。この仕様では、CoRE Resource Discoveryの新しい既知のリソース「/.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」は、サーバー上のリソースインターフェイスのエントリポイントへのリンクを返すために使用されることを意図しています。たとえばインデックスを作成するために、サーバーの他の場所にあるCoRE Link Formatリソースへのリンクを含めることで、より高度なリンク構成を実現できます。リンクがない場合、長さがゼロのペイロードが返されます。このリソースのリソース表現は、セクション2で説明されているCoREリンク形式でなければなりません。
The CoRE resource discovery interface supports the following interactions:
CoREリソースディスカバリインターフェイスは、次の相互作用をサポートしています。
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 「/.well-known/core」でデフォルトのポートに対してGETを実行すると、サーバーから利用可能な一連のリンク（存在する場合）が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」への要求をPOSTできるようにすることで、リソースディレクトリをサポートできます。ただし、そのようなリソースディレクトリ機能の詳細は、この仕様の範囲外であり、個別に指定されることが予想されます。
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のクエリ部分を、返されるリソースのフィルターとして認識してもよい（MAY）。パスとクエリのコンポーネントは共に、次のレベル4 URIテンプレート[RFC6570]に準拠する必要があります。
/.well-known/core{?search*}
where the variable "search" is a 1-element list that has a single name/value pair, where
ここで、変数「search」は、名前と値のペアが1つある1要素のリストです。
o name is either "href", a link-param name defined in this specification, or any other link-extension name, and
o nameは、「href」、この仕様で定義されているlink-param名、またはその他のリンク拡張名です。
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 valueは、「*」で終わらない完全な値の文字列（％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）。同様に、quoted-stringとして表記されているターゲット属性は、[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.
非常に制約されたノードがフィルタリングをサポートすることは期待されていません。フィルタリングをサポートしない実装は、クエリ文字列を単に無視して、ユニキャスト要求のリソース全体を返さなければなりません（MUST）。
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.
マルチキャスト要求をサポートするConstrained Application Protocol（CoAP）のような転送プロトコルを使用する場合は、特別な注意が必要です。フィルタリングがサポートされていない場合、またはフィルターが一致しない場合（不要な応答ストームを回避するため）、クエリ文字列を含むマルチキャスト要求に応答してはいけません（SHOULD NOT）。例外は、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 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という名前のターゲット属性を持つlink-valueに一致します。その値はbarで始まります（例：barまたはbarley）
o ?foo=* matches a link-value that has a target attribute named foo
o ？foo = *は、fooという名前のターゲット属性を持つlink-valueに一致します
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).
この例には、同じインターフェース記述を共有する2つの異なるセンサーへのリンクが含まれています。このリンク形式のデフォルトの関係タイプは、rel = target属性のないリンクでは「ホスト」であることに注意してください。したがって、この例のリンクは、/。well-known / coreが要求されたオリジンサーバー（コンテキスト）がリソース/ sensors / tempおよび/ sensors / light（各ターゲット）をホストしていることを示しています。
REQ: GET /.well-known/core
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"
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
RES: 2.05 Content
</sensors>;ct=40
REQ: GET /sensors
REQ：GET / sensors
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
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
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
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:
RES：2.05コンテンツ</ sensors>; ct = 40; title = "センサーインデックス"、</ sensors / temp>; rt = "気温-c"; if = "センサー"、</ sensors / light>; rt = "light-lux"; if = "sensor"、<http://www.example.com/sensors/t123>; anchor = "/ sensors / temp"; rel = "Descriptionby"、</ t>; anchor = "/ sensors / temp"; rel = "alternate"クライアントが特定のリソースに関する関係を見つけることに関心がある場合は、アンカーパラメータに対してクエリを実行できます。
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"
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).
次の例は、サイズ属性を持つ大きなファームウェアリソースを示しています。このリンクのコンシューマーは、 'sz'属性を使用して、リソース表現が大きすぎるかどうか、およびそれを要求するためにブロック転送が必要かどうかを判断します。この場合、64 KiBフラッシュしかないクライアントは、「sz」属性を格納するために16ビット整数しかサポートしない可能性があります。したがって、特別なフラグまたは値を使用して、 "Big"（64 KiBより大きい）を示す必要があります。
REQ: GET /.well-known/core?rt=firmware
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で説明されているものと同じセキュリティ上の考慮事項があります。 「/.well-known/core」リソースは、[COAP]のセクション9.1に従ってCoAPサーバーでホストされている場合、データグラムトランスポート層セキュリティ（DTLS）などを使用して保護できます（MAY）。
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）の認証機能をサポートし、サーバーがクライアントのIDと承認に基づいて異なるリンクのリストを返すことを許可する必要があります（SHOULD）。そのようなサーバーはすべてのリクエスターにすべてのリンクを返さない可能性がありますが、リンクを提供しないだけでは、関連リソースへのアクセスを制御しません-悪意のある人物が正しい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などの適切なオブジェクトセキュリティメカニズムを使用して保護されている場合にのみ受け入れられる必要があります（SHOULD）。
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.
CoREリンクフォーマットパーサーは、リンクの記述が循環的である、つまり、それ自体へのリンクを含んでいる可能性があることに注意する必要があります。これらの循環リンクは、直接的または間接的である可能性があります（つまり、参照リンクリソースを介して）。リンクの説明を解析し、循環リンクにアクセスするときは注意が必要です。
This memo registers the 'core' well-known URI in the Well-Known URIs registry as defined by [RFC5785].
このメモは[コア]既知のURIを[RFC5785]で定義されている既知の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」リソース表現として取得されるCoREで使用され、CoREリンクフォーマットのデフォルトのリレーションタイプです。
Application Data: None
アプリケーションデータ：なし
This memo registers the a new Internet media type for the CoRE Link Format, 'application/link-format'.
このメモは、CoREリンクフォーマットの新しいインターネットメディアタイプ「application / link-format」を登録します。
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などの適切なオブジェクトセキュリティメカニズムを使用して保護されている場合にのみ受け入れられる必要があります（SHOULD）。
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.
CoREリンクフォーマットパーサーは、リンクの記述が循環的である、つまり、それ自体へのリンクを含んでいる可能性があることに注意する必要があります。これらの循環リンクは、直接的または間接的である可能性があります（つまり、参照リンクリソースを介して）。リンクの説明を解析し、循環リンクにアクセスするときは注意が必要です。
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
Macintosh file type code(s):
Macintoshファイルタイプコード：
Intended usage: COMMON
使用目的：COMMON
Restrictions on usage: None Author: CoRE WG
使用上の制限：なし著者：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.
この仕様は、リンクターゲット属性値（[RFC5988]で定義）の2つの新しいサブレジストリを含む新しい制約付きRESTful環境（CoRE）パラメータレジストリを確立します。1つはリソースタイプ（rt =）リンクターゲット属性値用、もう1つはインターフェイスの説明（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.
どちらのサブレジストリでも、「core」という文字で始まる値は、IETFレビュー登録ポリシー[RFC5226]を使用して登録されます。他のすべての値は、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-type定義に準拠する必要があります。つまり、値は小文字のアルファベット文字で始まり、その後に一連の小文字のアルファベット、数字、「。」、または「-」文字が続き、次を含みます。空白はありません。
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は、これらの属性の拡張値として自由に使用するために予約されており、登録してはなりません（MUST NOT）。
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).
登録リクエストは、件名に明確にマークされたcore-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).
Designated Expertによる決定（またはその欠如）は、最初にApplication Area Directors（app-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、Peter Saint-Andreテキストを改善するコメントと貢献。
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 Dussealt、Alexey Melnikov、Gilbert Clark、Salvatore Loreto、ペトリムトカ、Szymon Sasin、Robert Quattlebaum、Robert Cragie、Angelo Castellani、Tomのおかげで文書を形作った有益なコメントと議論については、ハーブスト、エドベロセット、ギルマントーレ、ロビーシンプソン、コリンオフリン、デビッドライアン。
[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] Fielding、R.、Gettys、J.、Mogul、J.、Frystyk、H.、Masinter、L.、Leach、P。、およびT. Berners-Lee、「ハイパーテキスト転送プロトコル-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、「Uniform Resource Identifier（URI）：Generic Syntax」、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、「Media Type Specifications and Registration Procedures」、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、「RFCで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、「Tags for Identificationing Languages」、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。、「Webリンク」、RFC 5988、2010年10月。
[RFC6570] Gregorio, J., Fielding, R., Hadley, M., Nottingham, M., and D. Orchard, "URI Template", RFC 6570, March 2012.
[RFC6570]グレゴリオ、J。、フィールディング、R。、ハドリー、M。、ノッティンガム、M。、およびD.オーチャード、「URIテンプレート」、RFC 6570、2012年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、「Constrained Application Protocol（CoAP）」、Work in Progress、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。、「Architectural Styles and the Design of Network-based Software Architectures」、2000、<http://www.ics.uci.edu/~fielding/pubs/dissertation/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、「Multipurpose Internet Mail Extensions（MIME）Part One：Format of Internet Message Bodies」、RFC 2045、1996年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 2231、1997年11月。
[RFC4287] Nottingham, M., Ed. and R. Sayre, Ed., "The Atom Syndication Format", RFC 4287, December 2005.
[RFC4287]ノッティンガム、M。、エド。およびR.セイヤー編、「The Atom Syndication Format」、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、「IPv6 over Low-Power Wireless Personal Area Networks（6LoWPANs）：Overview、Assumptions、Problem Statement、and Goals」、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.ハマーラハブ、「Defining Well-Known Uniform Resource Identifiers（URIs）」、RFC 5785、2010年4月。
[RFC6454] Barth, A., "The Web Origin Concept", RFC 6454, December 2011.
[RFC6454]バース、A。、「The Web Origin Concept」、RFC 6454、2011年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 Specification」、World Wide Web Consortium Recommendation 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 Sensinode Kidekuja 2 Vuokatti 88600フィンランド
Phone: +358407796297
EMail: zach@sensinode.com