RFC 6415 - Web Host Metadata 日本語訳

URL : https://tools.ietf.org/html/rfc6415
タイトル : RFC 6415 - Webホストのメタデータ
翻訳編集 : 自動生成

Internet Engineering Task Force (IETF)              E. Hammer-Lahav, Ed.
Request for Comments: 6415                                       B. Cook
Category: Standards Track                                   October 2011
ISSN: 2070-1721

                           Web Host Metadata

Abstract

抽象

This specification describes a method for locating host metadata as well as information about individual resources controlled by the host.

この仕様は、ホスト・メタデータだけでなく、ホストによって制御される個々のリソースについての情報の位置を特定するための方法を記載しています。

Status of This Memo

このメモのステータス

This is an Internet Standards Track document.

これは、インターネット標準化過程文書です。

This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.

このドキュメントはインターネットエンジニアリングタスクフォース（IETF）の製品です。これは、IETFコミュニティの総意を表しています。これは、公開レビューを受けており、インターネットエンジニアリング運営グループ（IESG）によって公表のために承認されています。インターネット標準の詳細については、RFC 5741のセクション2で利用可能です。

Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6415.

このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報がhttp://www.rfc-editor.org/info/rfc6415で取得することができます。

著作権表示

著作権（C）2011 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

この文書では、BCP 78と、この文書の発行日に有効なIETFドキュメント（http://trustee.ietf.org/license-info）に関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクションで説明4.eおよび簡体BSDライセンスで説明したように、保証なしで提供されているよう簡体BSDライセンスのテキストを含める必要があり、この文書から抽出されました。

Table of Contents

   1. Introduction ....................................................2
      1.1. Example ....................................................3
           1.1.1. Processing Resource-Specific Information ............4
      1.2. Notational Conventions .....................................5
   2. Obtaining host-meta Documents ...................................6
   3. The host-meta Document ..........................................6
      3.1. XML Document Format ........................................7
           3.1.1. The "Link" Element ..................................7
   4. Processing host-meta Documents ..................................8
      4.1. Host-Wide Information ......................................9
      4.2. Resource-Specific Information ..............................9
   5. Security Considerations ........................................10
   6. IANA Considerations ............................................11
      6.1. The "host-meta" Well-Known URI ............................11
      6.2. The "host-meta.json" Well-Known URI .......................11
      6.3. The "lrdd" Relation Type ..................................11
   Appendix A. JRD Document Format ...................................12
   Appendix B. Acknowledgments .......................................15
   Normative References ..............................................15

1. Introduction

1. はじめに

Web-based protocols often require the discovery of host policy or metadata, where "host" is not a single resource but the entity controlling the collection of resources identified by Uniform Resource Identifiers (URIs) with a common URI host [RFC3986], which can be served by one or more servers.

「ホスト」は、単一のリソースでない場合、Webベースのプロトコルは、多くの場合、ホストポリシーやメタデータの発見を必要とするが、実体は一般的なURIのホスト[RFC3986]でユニフォームリソース識別子（URI）で識別されるリソースのコレクションを制御し、そのことができます1つ以上のサーバによって提供さ。

While web protocols have a wide range of metadata needs, they often use metadata that is concise, has simple syntax requirements, and can benefit from storing their metadata in a common location used by other related protocols.

ウェブプロトコルは、メタデータのニーズの広い範囲を持っていますが、彼らはしばしば簡潔でメタデータを使用し、単純な構文要件があり、そして他の関連するプロトコルによって使用される共通の場所にそのメタデータを保存するの恩恵を受けることができます。

Because there is no URI or representation available to describe a host, many of the methods used for associating per-resource metadata (such as HTTP headers) are not available. This often leads to the overloading of the root HTTP resource (e.g., 'http://example.com/') with host metadata that is not specific or relevant to the root resource itself.

いかなるURIまたはホストを記述するために利用可能な表現が存在しないため、（例えばHTTPヘッダなど）ごとのリソースメタデータを関連付けるために使用される方法の多くは利用できません。これは、多くの場合、ルートリソース自体に固有または関連していないホストメタデータとルートHTTPリソース（例えば、「http://example.com/」）のオーバーロードにつながります。

This document defines a lightweight metadata document format for describing hosts (thus the name "host-meta"), intended for use by web-based protocols. This document also registers the well-known URI suffix "host-meta" in the Well-Known URI Registry established by [RFC5785].

この文書では、Webベースのプロトコルで使用するためのもののホストを記述するための軽量なメタデータドキュメント形式（したがって名「ホスト・メタ」）を定義しています。この文書はまた、[RFC5785]によって確立されたよく知られているURIのレジストリではよく知られているURIの末尾に「ホスト・メタ」を登録します。

In addition, there are times when a host-wide scope for policy or metadata is too coarse-grained. host-meta provides two mechanisms for providing resource-specific information:

また、政策やメタデータのホスト全体のスコープがあまりにも粗粒であるがございます。ホスト・メタは、リソース固有の情報を提供するための2つのメカニズムを提供します。

o Link Templates - links using a URI template instead of a fixed target URI, providing a way to define generic rules for generating resource-specific links by applying the individual resource URI to the template.

Oリンクテンプレート - テンプレートに個々のリソースURIを適用することによって、リソース固有のリンクを生成するための一般的なルールを定義する方法を提供し、代わりに、固定ターゲットURIのURIテンプレートを使用してリンク。

o Link-based Resource Descriptor Documents (LRDD, pronounced 'lard') - descriptor documents providing resource-specific information, typically information that cannot be expressed using link templates. LRDD documents are linked to resources or host-meta documents using link templates with the "lrdd" relation type.

Oリンクベースのリソース記述子ドキュメント（LRDD、発音「ラード」） - リソース固有の情報を提供する記述文書、リンクテンプレートを使用して表現することはできません一般的な情報。 LRDD文書は「LRDD」関係タイプとのリンクテンプレートを使用してリソースまたはホストメタ文書にリンクされています。

1.1. Example

1.1. 例

The following is a simple host-meta document including both host-wide and resource-specific information for the 'example.com' host:

以下は、「example.com」ホストのホスト全体およびリソース固有の情報の両方を含む単純なホスト - メタ文書です。

<?xml version='1.0' encoding='UTF-8'?> <XRD xmlns='http://docs.oasis-open.org/ns/xri/xrd-1.0'>

<？xmlのバージョン= '1.0' エンコーディング= 'UTF-8'？> <XRDののxmlns = 'のhttp：//docs.oasis-open.org/ns/xri/xrd-1.0'>

<！ - ホスト全体の情報 - >

<不動産の種類= 'のhttp：//protocol.example.net/version'> 1.0 </プロパティ>

<リンクのrel = '著作権' のhref = 'のhttp：//example.com/copyright' />

<！ - リソース固有の情報 - >

<リンクのrel = 'ハブ' テンプレート= 'のhttp：//example.com/hub' />

<リンクREL = 'LRDD' TYPE = 'アプリケーション/ XRD + XML' 鋳型= 'HTTP：//example.com/lrdd URI = {URI}' />

<リンクのrel = '著者のテンプレート= 'のhttp：？//example.com/author Q = {URI}'/>

</XRD>

</ XRD>

The host-wide information that applies to the host in its entirety provided by the document includes:

文書が含まによって提供その全体がホストに適用されるホスト全体の情報：

o An "http://protocol.example.net/version" host property with a value of "1.0".

O「1.0」の値が「http://protocol.example.net/version」ホストプロパティ。

o A link to the host's copyright policy ("copyright").

ホストの著作権ポリシー（「著作権」）へのリンクO。

The resource-specific information provided by the document includes:

文書が提供するリソース固有の情報が含まれています：

o A link template for receiving real-time updates ("hub") about individual resources. Since the template does not include a template variable, the target URI is identical for all resources.

個々のリソースに関するリアルタイムの更新（「ハブ」）を受信するためのリンクテンプレートO。テンプレートは、テンプレート変数が含まれていないので、ターゲットURIは、すべてのリソースに対して同じです。

o A LRDD document link template ("lrdd") for obtaining additional resource-specific information contained in a separate document for each individual resource.

各個々のリソースのための別の文書に含まれる追加のリソース固有の情報を取得するためLRDD文書リンクテンプレート（「LRDD」）O。

o A link template for finding information about the author of individual resources ("author").

個々のリソース（「作者」）の著者に関する情報を見つけるためのリンクテンプレートO。

1.1.1. Processing Resource-Specific Information

1.1.1. 処理リソース固有の情報

When looking for information about an individual resource -- for example, the resource identified by 'http://example.com/xy' -- the resource URI is applied to the templates found, producing the following links:

個々のリソースについての情報を探しているとき - 例えば、「http://example.com/xy」によって識別されるリソース - リソースURIは以下のリンクを生成する、見つかったテンプレートに適用されます。

<リンクのrel = 'ハブ' のhref = 'のhttp：//example.com/hub' />

<リンクのrel = 'LRDD' タイプ= 'アプリケーション/ XRD + xmlの' のhref = 'のhttp：？//example.com/lrdd URI =のhttp％3A％2F％2Fexample.com％2Fxy' />

<リンクのrel = '作者' のhref = 'のhttp：？//example.com/author Q =のhttp％3A％2F％2Fexample.com％2Fxy' />

The LRDD document for 'http://example.com/xy' (obtained via an HTTP "GET" request):

「http://example.com/xy」（HTTP経由で取得した「GET」リクエスト）のためのLRDDドキュメント：

<?xml version='1.0' encoding='UTF-8'?> <XRD xmlns='http://docs.oasis-open.org/ns/xri/xrd-1.0'>

<？xmlのバージョン= '1.0' エンコーディング= 'UTF-8'？> <XRDののxmlns = 'のhttp：//docs.oasis-open.org/ns/xri/xrd-1.0'>

<Subject>http://example.com/xy</Subject>

<件名> http://example.com/xy </件名>

<不動産の種類= 'のhttp：//spec.example.net/color'>赤</プロパティ>

<リンクのrel = 'ハブ' のhref = 'のhttp：//example.com/another/hub' />

<リンクのrel = '作者' のhref = 'のhttp：//example.com/john' /> </ XRD>

Together, the information available about the individual resource (presented as an Extensible Resource Descriptor (XRD) document for illustration purposes) is:

一緒に、（例示の目的のために、拡張リソース記述子（XRD）文書として表示）は、個々のリソースに関する利用可能な情報です。

<?xml version='1.0' encoding='UTF-8'?> <XRD xmlns='http://docs.oasis-open.org/ns/xri/xrd-1.0'>

<？xmlのバージョン= '1.0' エンコーディング= 'UTF-8'？> <XRDののxmlns = 'のhttp：//docs.oasis-open.org/ns/xri/xrd-1.0'>

<Subject>http://example.com/xy</Subject>

<件名> http://example.com/xy </件名>

<不動産の種類= 'のhttp：//spec.example.net/color'>赤</プロパティ>

<リンクのrel = 'ハブ' のhref = 'のhttp：//example.com/hub' />

<リンクのrel = 'ハブ' のhref = 'のhttp：//example.com/another/hub' />

<リンクのrel = '作者' のhref = 'のhttp：//example.com/john' />

<リンクのrel = '作者' のhref = 'のhttp：？//example.com/author Q =のhttp％3A％2F％2Fexample.com％2Fxy' />

</XRD>

</ XRD>

Note that the order of links matters and is based on their original order in the host-meta and LRDD documents. For example, the "hub" link obtained from the host-meta link template has a higher priority than the link found in the LRDD document because the host-meta link appears before the "lrdd" link.

リンクの順序が重要とホスト・メタおよびLRDD文書に元の順序に基づいていることに注意してください。ホスト・メタリンクは「LRDD」リンクの前に表示されますので、例えば、ホスト・メタリンクテンプレートから取得した「ハブ」のリンクがLRDDドキュメントで見つかったリンクよりも優先順位が高いです。

On the other hand, the "author" link found in the LRDD document has a higher priority than the link found in the host-meta document because it appears after the "lrdd" link.

それは「LRDD」リンク後に表示されるので、一方、LRDDドキュメントで見つかった「著者」のリンクは、ホストメタ文書で見つかったリンクよりも優先順位が高いです。

1.2. Notational Conventions

1.2. 表記規則

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].

キーワード "MUST"、 "MUST NOT"、 "REQUIRED"、 "SHALL"、 "SHOULD"、 "ないもの"、 "推奨" "ない（SHOULD NOT）"、 "MAY"、 "推奨NOT"、および「OPTIONAL 「本書では[RFC2119]で説明されるように解釈されるべきです。

This document uses the Augmented Backus-Naur Form (ABNF) notation of [RFC5234]. Additionally, the following rules are included from [RFC3986]: reserved, unreserved, and pct-encoded.

このドキュメントは[RFC5234]の増補バッカス - ナウアフォーム（ABNF）の表記を使用します。予約され、予約されていない、及びPCT-符号化：また、以下の規則は、[RFC3986]に含まれています。

2. Obtaining host-meta Documents

2.ホスト・メタドキュメントの取得

The client obtains the host-meta document for a given host by sending an HTTP [RFC2616] or an HTTPS [RFC2818] GET request to the host for the "/.well-known/host-meta" path, using the default ports defined for each protocol (e.g., port 80 for HTTP and port 443 for HTTPS). The scope and meaning of host-meta documents obtained via other protocols or ports is undefined.

クライアントは、定義されたデフォルトのポートを使用して、HTTP [RFC2616]またはHTTPS [RFC2818]は「/.well-known/host-meta」パスのホストへのリクエストをGET送信することにより、特定のホストのホスト・メタ文書を取得し、各プロトコル（HTTPおよびHTTPS用のポート443のために、例えば、ポート80）のために。他のプロトコルやポートを介して取得したホスト - メタ文書の範囲と意味が定義されていません。

The server MUST support at least one protocol but MAY support both. If both protocols are supported, they MUST produce the same document.

サーバーには、少なくとも1つのプロトコルをサポートしなければならないが、両方をサポートすることができます。両方のプロトコルがサポートされている場合、それらは同じ文書を作成しなければなりません。

The decision as to which protocol is used to obtain the host-meta document has significant security ramifications, as described in Section 5.

第5節で説明したようにどのプロトコルに関する決定は、ホスト・メタ文書の重要なセキュリティ上の波及効果を持っているを取得するために使用されます。

For example, the following request is used to obtain the host-meta document for the 'example.com' host:

たとえば、次のリクエストは、「example.com」ホスト用のホスト・メタ文書を取得するために使用されます。

GET /.well-known/host-meta HTTP/1.1 Host: example.com

GET /.well-known/host-meta HTTP / 1.1ホスト：example.com

If the server response indicates that the host-meta resource is located elsewhere (a 301, 302, or 307 response status code), the client SHOULD try to obtain the resource from the location provided in the response. This means that the host-meta document for one host MAY be retrieved from another host. Likewise, if the resource is not available or does not exist (e.g., a 404 or 410 response status code), the client SHOULD infer that metadata is not available via this mechanism.

サーバ応答がホストメタリソースは（301、302、または307応答ステータスコード）他の場所に配置されていることを示す場合、クライアントは、応答内に設けられた場所からリソースを取得するようにしてください。これは、1つのホストのホストメタ文書は別のホストから取得することができることを意味します。リソースが利用可能でないか、または（例えば、404のまたは410応答ステータスコード）が存在しない場合は同様に、クライアントはそのメタデータを推測すべきである。このメカニズムを介して利用できません。

The host-meta document SHOULD be served with the "application/xrd+xml" media type.

ホスト・メタ文書は、「アプリケーション/ XRD + xml」でメディアタイプを添えすべきである（SHOULD）。

3. The host-meta Document

3.ホスト・メタドキュメント

The host-meta document uses the XRD 1.0 document format as defined by [OASIS.XRD-1.0], which provides a simple and extensible XML-based schema for describing resources. This specification defines additional processing rules needed to describe hosts. Documents MAY include any elements included in the XRD 1.0 schema that are not explicitly excluded by this specification.

[OASIS.XRD-1.0]、リソースを記述するための単純で拡張可能なXMLベースのスキーマを提供することによって定義されるような宿主 - メタ文書は、XRD 1.0文書フォーマットを使用します。この仕様は、ホストを記述するために必要な追加の処理規則を定義します。文書は、明示的にこの仕様によって除外されていませんXRD 1.0スキーマに含まれるすべての要素を含むことができます。

The server MAY offer alternative representations of any XRD document it serves (host-meta, LRDD, or other XRD-based documents). The client MAY request a particular representation using the HTTP "Accept" request header field. If no "Accept" request header field is included with the request, or if the client requests an "application/xrd+xml" representation, the server MUST respond using the REQUIRED XRD 1.0 XML representation described in Section 3.1.

サーバは、それがサービスを提供する任意のXRDドキュメント（ホスト - メタ、LRDD、またはその他のXRDベースの文書）の代替表現を提供することがあります。クライアントは、HTTPリクエストヘッダフィールドを「受け入れる」を使用して特定の表現を要求することができます。何の「同意する」リクエストヘッダフィールドがリクエストに含まれていない場合、クライアントは、「アプリケーション/ XRD + xml」で表現を要求した場合、または、サーバは、3.1節で説明REQUIRED XRD 1.0 XML表現を使用して応答しなければなりません。

Applications using the host-meta document MAY require the server to provide a specific alternative representation in addition to the XRD 1.0 XML representation when explicitly requested by the client.

ホスト・メタ文書を使用するアプリケーションは、明示的にクライアントによって要求されたときにXRD 1.0 XML表現に加えて、特定の代替表現を提供するために、サーバーが必要な場合があります。

A JavaScript Object Notation (JSON) Resource Descriptor, known as JRD, is described in Appendix A. It is RECOMMENDED that servers offer the JRD representation in addition to the XRD representation.

JavaScriptのオブジェクト表記JRDとして知られている（JSON）リソース記述は、付録Aに記載されたサーバがXRD表現に加えて、JRD表現を提供することが推奨されます。

3.1. XML Document Format

3.1. XMLドキュメントの形式

The host-meta document root MUST be an "XRD" element. The document SHOULD NOT include a "Subject" element, as at this time no URI is available to identify hosts. The use of the "Alias" element in host-meta is undefined and NOT RECOMMENDED.

ホスト・メタドキュメントルートは、「XRD」の要素でなければなりません。この時点では何のURIがホストを識別するために利用されないよう文書では、「件名」要素を含めるべきではありません。ホスト・メタの「エイリアス」要素の使用は未定義と推奨されません。

The subject (or "context IRI", as defined by [RFC5988]) of the XRD "Property" and "Link" elements is the host described by the host-meta document. However, the subject of "Link" elements with a "template" attribute is the individual resource whose URI is applied to the link template, as described in Section 3.1.1.

XRD「プロパティ」と「リンク」の要素（[RFC5988]で定義されるような、または「文脈IRI」）被験者は、ホストメタドキュメントによって記述ホストです。しかし、「テンプレート」属性と「リンク」要素の主題は、そのURIセクション3.1.1で説明したように、リンク・テンプレートに適用され、個々のリソースです。

3.1.1. The "Link" Element

3.1.1. 「リンク」の要素

The XRD "Link" element, when used with the "href" attribute, conveys a link relation between the host described by the document and a common target URI.

XRDは、「リンク」要素は、「HREF」属性で使用した場合、文書と共通のターゲットURIによって記述ホスト間のリンク関係を伝えます。

For example, the following link declares a common copyright license for the entire scope:

たとえば、次のリンクは全体のスコープのための共通の著作権ライセンスを宣言します。

<リンクのrel = '著作権' のhref = 'のhttp：//example.com/copyright' />

However, a "Link" element with a "template" attribute conveys a relation whose context is an individual resource within the host-meta document scope, and whose target is constructed by applying the context resource URI to the template. The template string MAY contain a URI string without any variables to represent a resource-level relation that is identical for every individual resource.

しかし、「テンプレート」属性を持つ「リンク」の要素は、そのコンテキストターゲットテンプレートにコンテキストリソースURIを適用することにより構成され、個々のホスト・メタ文書スコープ内のリソース、およびある関係を伝えます。テンプレート文字列は、すべての個々のリソースに対して同じであるリソース・レベルの関係を表現するために任意の変数を使用せずにURI文字列を含むかもしれません。

For example, a blog with multiple authors can provide information about each article's author by providing an endpoint with a parameter set to the URI of each article. Each article has a unique author, but all share the same pattern of where that information is located:

例えば、複数の著者とのブログは、各記事のURIに設定されたパラメータを持つエンドポイントを提供することにより、各記事の著者に関する情報を提供することができます。各記事には、ユニークな著者を持っていますが、すべては、その情報がどこにあるのと同じパターンを共有します：

<リンクのrel = '著者のテンプレート= 'のhttp：？//example.com/author記事= {URI}'/>

3.1.1.1. Template Syntax

3.1.1.1。テンプレートの構文

This specification defines a simple template syntax for URI transformation. A template is a string containing brace-enclosed ("{}") variable names marking the parts of the string that are to be substituted by the corresponding variable values.

この仕様は、URI変換のためのシンプルなテンプレート構文を定義します。テンプレートは、括弧で囲まれたを含む文字列（「{}」）に対応する変数の値によって置換される文字列の部分をマーキング変数名です。

Before substituting template variables, values MUST be encoded using UTF-8, and any character other than unreserved (as defined by [RFC3986]) MUST be percent-encoded per [RFC3986].

テンプレート変数を代入する前に、値は、UTF-8を使用して符号化されなければならない、および（[RFC3986]で定義されるように）予約されていない以外の任意の文字は[RFC3986]あたりのパーセントエンコードされなければなりません。

This specification defines a single variable -- "uri" -- as the entire context resource URI. Protocols MAY define additional relation-specific variables and syntax rules, but SHOULD only do so for protocol-specific relation types, and MUST NOT change the meaning of the "uri" variable. If a client is unable to successfully process a template (e.g., unknown variable names, unknown or incompatible syntax), the parent "Link" element SHOULD be ignored.

全体コンテキストリソースURIとして - 「URI」 - この仕様は、単一の変数を定義します。プロトコルは、関係固有の変数と構文規則の追加を定義するかもしれないが、唯一のプロトコル固有の関係タイプのためにそうするべきであり、「URI」変数の意味を変えてはなりません。クライアントが正常にテンプレートを処理することができない場合（例えば、未知の変数名、不明または互換性のない構文が）、親の「リンク」の要素は無視されるべきです。

The template syntax ABNF follows:

テンプレートの構文ABNFは次のとおりです。

URI-Template = *( uri-char / variable ) variable = "{" var-name "}" uri-char = ( reserved / unreserved / pct-encoded ) var-name = %x75.72.69 / ( 1*var-char ) ; "uri" or other names var-char = ALPHA / DIGIT / "." / "_"

URIテンプレート= *（URI-チャー/変数）変数= "{" VAR名 "}" URI-CHAR =（予約/予約されていない/ PCTエンコード）VAR-NAME =％x75.72.69 /（1 * var- CHAR）; "ウリ" または他の名前VAR-CHAR = ALPHA / DIGIT / "" / "_"

For example:

例えば：

Input: http://example.com/r?f=1 Template: http://example.org/?q={uri} Output: http://example.org/?q=http%3A%2F%2Fexample.com%2Fr%3Ff%3D1

入力：http://example.com/r?f=1テンプレート：http://example.org/?q={uri}出力：http://example.org/?q=http%3A%2F% 2Fexample.com％2FR％3FF％3D1

4. Processing host-meta Documents

4.処理ホスト - メタドキュメント

Once the host-meta document has been obtained, the client processes its content based on the type of information desired: host-wide or resource-specific.

ホスト全体またはリソース固有：ホストメタ文書が得られたら、クライアントが希望する情報の種類に基づいて、そのコンテンツを処理します。

Clients usually look for a link with a specific relation type or other attributes. In such cases, the client does not need to process the entire host-meta document and all linked LRDD documents, but instead process the various documents in their prescribed order until the desired information is found.

クライアントは通常、特定の関係の種類や他の属性とのリンクを探してください。このような場合には、クライアントは、ホスト全体-メタ文書とリンクされているすべてのLRDD文書を処理する必要はありませんが、代わりに、必要な情報が発見されるまで、その規定のために、様々な文書を処理します。

Protocols using host-meta must indicate whether the information they seek is host-wide or resource-specific -- for example, "obtain the first host-meta resource-specific link using the 'author' relation type". If both types are used for the same purpose (e.g., first look for resource-specific, then look for host-wide), the protocol must specify the processing order.

ホスト・メタを使用するプロトコルは、彼らが求める情報はホスト全体またはリソース固有であるかどうかを示す必要があります - 例えば、「「著者の関係タイプを使用して、最初のホスト・メタリソース固有のリンクを得ます」。両方のタイプは、（例えば、リソース固有の最初の外観を、ホスト全体を探して）同じ目的のために使用される場合、プロトコルは、処理順序を指定する必要があります。

4.1. Host-Wide Information

4.1. ホスト全体の情報

When looking for host-wide information, the client MUST ignore any "Link" elements with a "template" attribute, as well as any link using the "lrdd" relation type. All other elements are scoped as host-wide.

ホスト全体の情報を探しているときに、クライアントが「LRDD」関係タイプを使用して「テンプレート」属性だけでなく、任意のリンクを持つ任意の「リンク」の要素を無視しなければなりません。他のすべての要素は、ホスト全体としてスコープされています。

4.2. Resource-Specific Information

4.2. リソース固有の情報

Unlike host-wide information, which is contained solely within the host-meta document, resource-specific information is obtained from host-meta link templates, as well as from linked LRDD documents.

単にホスト・メタ文書内に含まれているホスト全体の情報とは異なり、リソース固有の情報は、ホスト・メタリンクのテンプレートから、だけでなく、リンクされLRDD文書から得られます。

When looking for resource-specific information, the client constructs a resource descriptor by collecting and processing all the host-meta link templates. For each link template:

リソース固有の情報を探している場合は、クライアントはすべてのホスト・メタリンクテンプレートを収集し、処理することによって、リソース記述子を構築します。各リンクテンプレートの場合：

1. The client applies the URI of the desired resource to the template, producing a resource-specific link.

1.クライアントは、リソース固有のリンクを作成、テンプレートに必要なリソースのURIを適用します。

2. If the link's relation type is other than "lrdd", the client adds the link to the resource descriptor in order.

2.リンクの関係タイプは「LRDD」以外の場合、クライアントは順番にリソース記述子へのリンクを追加します。

3. If the link's relation type is "lrdd":

3.リンクの関係タイプは「LRDD」の場合：

       3.1.  The client obtains the LRDD document by following the
             scheme-specific rules for the LRDD document URI.  If the
             document URI scheme is "http" or "https", the document is
             obtained via an HTTP "GET" request to the identified URI.
             If the HTTP response status code is 301, 302, or 307, the
             client MUST follow the redirection response and repeat the
             request with the provided location.

3.2. The client adds any links found in the LRDD document to the resource descriptor in order, except for any link using the "lrdd" relation type (processing is limited to a single level of inclusion). When adding links, the client SHOULD retain any extension attributes and child elements if present (e.g., <Property> or <Title> elements).

3.2. クライアントは、「LRDD」関係型（処理が包含の単一レベルに制限されている）を使用して任意のリンクを除いて、順番にリソース記述子にLRDD文書で見つかった任意のリンクを追加します。リンクを追加する場合（例えば、<プロパティ>または<タイトル>要素）存在する場合、クライアントは任意の拡張属性と子要素を保持しなければなりません。

3.3. The client adds any resource properties found in the LRDD document to the resource descriptor in order (e.g., <Alias> or <Property> child elements of the LRDD document <XRD> root element).

3.3. クライアントが順番にリソース記述子にLRDDドキュメントで見つかったリソースプロパティを追加します（例えば、<エイリアス>または<プロパティ> LRDD文書の子要素<XRD>ルート要素）。

5. Security Considerations

5.セキュリティについての考慮事項

The host-meta document is designed to be used by other applications explicitly "opting-in" to use the facility. Therefore, any such application MUST review the specific security implications of using host-meta documents. By itself, this specification does not provide any protections or guarantees that any given host-meta document is under the control of the appropriate entity as required by each application.

ホスト・メタ文書は、「オプトイン」機能を使用するために、明示的に他のアプリケーションで使用されるように設計されています。そのため、どのようなアプリケーションは、ホスト・メタ文書を使用して、特定のセキュリティへの影響を確認する必要があります。それ自体で、本明細書では、任意の保護を提供したり、各アプリケーションによって要求される任意のホストメタ文書が適切なエンティティの制御下にあることを保証しません。

The metadata returned by the host-meta resource is presumed to be under the control of the appropriate authority and representative of all the resources described by it. If this resource is compromised or otherwise under the control of another party, it may represent a risk to the security of the server and data served by it, depending on the applications using it.

ホスト・メタリソースによって返されたメタデータは、それによって記述されているすべてのリソースの適切な権限と代表の制御下であると推定されます。このリソースは、他の当事者の制御下で障害が起きたりした場合、それを使用するアプリケーションに応じて、それによって提供されるサーバとデータのセキュリティにリスクを表すことができます。

Applications utilizing the host-meta document where the authenticity of the information is necessary MUST require the use of the HTTPS protocol and MUST NOT produce a host-meta document using other means. In addition, such applications MUST require that any redirection leading to the retrieval of a host-meta document also utilize the HTTPS protocol.

情報の信憑性が必要であるホスト・メタ文書を利用するアプリケーションは、HTTPSプロトコルの使用を必要としなければならないし、他の手段を使用してホスト・メタ文書を作成してはなりません。加えて、そのようなアプリケーションは、ホストメタ文書の検索を導く任意のリダイレクトはまた、HTTPSプロトコルを利用することを要求しなければなりません。

Since the host-meta document is authoritative for the entire host, not just the authority (combination of scheme, host, and port) of the host-meta document server, applications MUST ensure that using a host-meta document for another URI authority does not represent a potential security exploit.

ホスト・メタ文書は、ホスト・メタドキュメントサーバのホスト全体だけではなく、権威（スキーム、ホストの組み合わせ、およびポート）に対して権限を持っているので、アプリケーションは別のURIの権威のためにホスト・メタ文書を使用することはないことを保証しなければなりません潜在的なセキュリティを悪用表すものではありませ。

Protocols using host-meta templates must evaluate the construction of their templates as well as any protocol-specific variables or syntax to ensure that the templates cannot be abused by an attacker. For example, a client can be tricked into following a malicious link due to a poorly constructed template that produces unexpected results when its variable values contain unexpected characters.

ホスト・メタテンプレートを使用したプロトコルは、テンプレートは、攻撃者によって悪用されることができないことを保証するために、そのテンプレートの構築だけでなく、任意のプロトコル固有の変数や構文を評価しなければなりません。例えば、クライアントは、その変数の値が予期しない文字が含まれているときに予期しない結果を生む不十分構築テンプレートに悪質なリンクを以下のようにだまさすることができます。

6. IANA Considerations

6. IANAの考慮事項

6.1. The "host-meta" Well-Known URI

6.1. 「ホスト・メタ」よく知られているURI

This specification registers the "host-meta" well-known URI in the Well-Known URI Registry as defined by [RFC5785].

[RFC5785]で定義されたこの仕様は、よく知られているURIのレジストリではよく知られているURI「のホスト・メタ」を登録します。

URI suffix: host-meta

URIサフィックス：ホスト - メタ

Change controller: IETF

変更コントローラ：IETF

Specification document(s): RFC 6415

仕様書（S）：RFC 6415

Related information: The "host-meta" documents obtained from the same host using the HTTP and HTTPS protocols (using default ports) MUST be identical.

関連情報：（デフォルトのポートを使用して）HTTPおよびHTTPSプロトコルを使用して、同じホストから取得した「ホスト・メタ」の文書は同じでなければなりません。

6.2. The "host-meta.json" Well-Known URI

6.2. 「ホストmeta.json」既知のURI

This specification registers the "host-meta.json" well-known URI in the Well-Known URI Registry as defined by [RFC5785].

[RFC5785]で定義されたこの仕様は、「ホストmeta.json」既知のURIレジストリではよく知られているURIを登録します。

URI suffix: host-meta.json

URIサフィックス：ホストmeta.json

Change controller: IETF

変更コントローラ：IETF

Specification document(s): RFC 6415

仕様書（S）：RFC 6415

Related information: The "host-meta.json" documents obtained from the same host using the HTTP and HTTPS protocols (using default ports) MUST be identical.

関連情報：（デフォルトのポートを使用して）HTTPおよびHTTPSプロトコルを使用して、同じホストから取得した「ホストmeta.json」の文書は同じでなければなりません。

6.3. The "lrdd" Relation Type

6.3. 「LRDD」関係タイプ

This specification registers the "lrdd" relation type in the Link Relation Type Registry defined by [RFC5988]:

この仕様は、[RFC5988]で定義されたリンク関係タイプレジストリに「LRDD」関係タイプを登録します。

Relation Name: lrdd

リレーション名：LRDD

Description: Refers to further information about the link's context, expressed as a LRDD ("Link-based Resource Descriptor Document") resource. See RFC 6415 for information about processing this relation type in host-meta documents. When used elsewhere, it refers to additional links and other metadata. Multiple instances indicate additional LRDD resources. LRDD resources MUST have an "application/xrd+xml" representation, and MAY have others.

説明：リンクのコンテキストに関する詳細情報を参照し、LRDD（「リンクベースのリソース記述文書」）のリソースとして表現。ホスト・メタ文書で、この関係タイプを処理する方法については、RFC 6415を参照してください。他の場所で使用する場合、それは追加のリンクや他のメタデータを参照します。複数のインスタンスを追加LRDDリソースを示しています。 LRDDリソースは、「アプリケーション/ XRD + xml」で表現を持たなければならない、と他の人を持っているかもしれません。

Reference: RFC 6415

参考：RFC 6415

Appendix A. JRD Document Format

付録A. JRDドキュメントフォーマット

The JRD document format -- a general-purpose XRD 1.0 representation -- uses the JavaScript Object Notation (JSON) format defined in [RFC4627]. JRD uses the same elements and processing rules described in Section 3.1. The JRD format is designed to include the same base functionality provided by the XML format, with the exception of extensibility, as extensibility is beyond the scope of this specification.

JRD文書フォーマット - 汎用XRD 1.0表現は - [RFC4627]で定義されたJavaScriptオブジェクト表記（JSON）フォーマットを使用します。 JRDは3.1節で説明したのと同じ要素及び処理ルールを使用します。拡張性は、本明細書の範囲外であるとしてJRDフォーマットは、拡張を除いて、XMLフォーマットで提供される同一の基本機能を含むように設計されています。

The client MAY request a JRD representation using the HTTP "Accept" request header field with a value of "application/json". The server MUST include the HTTP "Content-Type" response header field with a value of "application/json". Any other "Content-Type" value (or lack thereof) indicates that the server does not support the JRD format.

クライアントは、「アプリケーション/ JSON」の値でHTTP「同意する」要求ヘッダフィールドを使用して、JRD表現を要求することができます。サーバは、「アプリケーション/ JSON」の値を持つHTTP「コンテンツタイプ」レスポンスヘッダフィールドを含まなければなりません。その他の「Content-Typeの」値（またはその欠如）サーバはJRD形式をサポートしていないことを示しています。

Alternatively, the client MAY request a JRD representation by requesting the "host-meta.json" well-known document, by making a GET request for "/.well-known/host-meta.json", following the same process used for "/.well-known/host-meta". If the server does not support serving a JRD representation at this location, the server MUST respond with an HTTP 404 (Not Found) status code.

また、クライアントがに使用したのと同じプロセスに続いて、「/.well-known/host-meta.json」のためのGET要求を行うことにより、「ホストmeta.json」よく知られた文書を要求することにより、JRD表現を要求することができます"/.well-known/host-meta"。サーバはこの場所でJRD表現を提供しサポートしていない場合、サーバーはHTTP 404（見つかりません）ステータスコードで応じなければなりません。

XRD elements are serialized into a JSON object as follows:

次のようにXRD要素は、JSONオブジェクトにシリアル化されます。

o The XML document declaration and "XRD" element are discarded.

OのXML文書宣言と「XRD」要素は破棄されます。

o The "Subject" element is included as a name/value pair with the name 'subject', and value included as a string.

O「件名」要素は、名称「件名」と名前/値ペアとして含まれ、その値は、文字列として含まれています。

o The "Expires" element is included as a name/value pair with the name 'expires', and value included as a string.

O「期限切れ」要素は、名前の名前/値のペアが「期限切れになる」として含まれ、その値は、文字列として含まれています。

o "Alias" elements are included as a single name/value pair with the name 'aliases', and value a string array containing the values of each element in order.

O「エイリアス」の要素は、単一の名前/値の名前「エイリアス」と対、および値として順に各要素の値を含む文字列配列が含まれます。

o "Property" elements are included as a single name/value pair with the name 'properties', and value an object with each element included as a name/value pair with the value of the "type" attribute as name, and element value included as a string value. The values of properties with empty values (i.e., using the REQUIRED "xsi:nil='true'" attribute) are included as null. If more than one "Property" element is present with the same "type" attribute, only the last instance is included.

O「プロパティ」要素は、単一の名前/値の「プロパティ」名前の対、及び各要素を持つオブジェクトの名前として、「タイプ」属性の値を持つ名前/値ペアとして含まれる値、及び要素値として含まれています文字列値として含まれています。空の値（「XSI：なし= 『真』」、すなわち、REQUIREDを使用して属性）を持つプロパティの値がヌルとして含まれます。複数の「プロパティ」の要素が同じ「タイプ」属性が存在する場合は、最後のインスタンスのみが含まれています。

o "Link" elements are included as a single name/value pair with the name 'links', and value an array with each element included as an object. Each attribute is included as a name/value pair with the attribute name as name, and value included as a string.

O「リンク」の要素は、名前「リンク」を持つ単一の名前/値ペアとして含まれ、その値の各要素の配列は、オブジェクトとして含まれています。各属性は、名前のように属性名を持つ名前/値ペアとして含まれ、値が文字列として含まれています。

o "Link" child "Property" elements are included using the same method as XRD-level "Property" elements using a name/value pair inside the link object.

O「リンク」子「プロパティ」要素は、リンクオブジェクト内の名前/値ペアを使用してXRDレベル「プロパティ」の要素と同様の方法を使用して含まれています。

o "Link" child "Title" elements are included as a single object with the name 'titles', and value an object with each element included as a name/value pair with the value of the "xml:lang" attribute as name, and element value included as a string value. The names of elements without an "xml:lang" attribute are added with the name 'default'. If more than one "Title" element is present with the same (or no) "xml:lang" attribute, only the last instance is included.

O「リンク」子「タイトル」要素は、単一の名前のタイトル」のオブジェクト、および各要素を持つオブジェクトは、「XML：LANG」の値を持つ名前/値のペアとして含まれる値として含まれている名前と属性、要素の値は、文字列値として含まれています。「XML：LANG」のない要素の名前属性は、名前「デフォルト」に追加されます。複数の「タイトル」要素は同じ（あるいは全く）「のxml：langの」とある場合は、属性、最後のインスタンスのみが含まれています。

o The conversion of any other element is left undefined.

O任意の他の要素の変換は、未定義のままです。

For example, the following XRD document...

たとえば、次のようXRDドキュメント...

<?xml version='1.0' encoding='UTF-8'?> <XRD xmlns='http://docs.oasis-open.org/ns/xri/xrd-1.0' xmlns:xsi='http://www.w3.org/2001/XMLSchema-instance'>

<？xmlのバージョン= '1.0' エンコーディング= 'UTF-8'？> <XRDののxmlns = 'のhttp：//docs.oasis-open.org/ns/xri/xrd-1.0' のxmlns：XSI = 'のhttp：/ /www.w3.org/2001/XMLSchema-instance '>

<Subject>http://blog.example.com/article/id/314</Subject> <Expires>2010-01-30T09:30:00Z</Expires>

<テーマ> http://blog.example.com/article/id/314 </件名> 2010-01-30T09 <有効期限>：30：00Z </有効期限>

<Alias>http://blog.example.com/cool_new_thing</Alias> <Alias>http://blog.example.com/steve/article/7</Alias>

<エイリアス> http://blog.example.com/cool_new_thing </エイリアス> <エイリアス> http://blog.example.com/steve/article/7 </エイリアス>

<不動産の種類= 'のhttp：//blgx.example.net/ns/version'> 1.2 </プロパティ> <不動産の種類= 'のhttp：//blgx.example.net/ns/version'> 1.3 </プロパティ> <不動産の種類= 'のhttp：//blgx.example.net/ns/ext' XSI：nilを= '真' />

<Link rel='author' type='text/html' href='http://blog.example.com/author/steve'> <Title>About the Author</Title> <Title xml:lang='en-us'>Author Information</Title> <Property type='http://example.com/role'>editor</Property> </Link>

<リンクのrel = '作者' タイプ= 'text / htmlの' のhref = 'のhttp：//blog.example.com/author/steve'> <タイトル>著者</ TITLE> <タイトルXMLについて：LANG = 'エン-us '>著者情報</ TITLE> <不動産の種類=' のhttp：//example.com/role '>エディタ</プロパティ> </リンク>

<Link rel='author' href='http://example.com/author/john'> <Title>The other guy</Title> <Title>The other author</Title> </Link>

<リンクのrel = '作者' のhref = 'のhttp：//example.com/author/john'> <タイトル>他の男</ TITLE> <タイトル>その他の著者</ TITLE> </リンク>

<リンクのrel = '著作権' テンプレート= 'のhttp：？//example.com/copyright ID = {URI}' /> </ XRD>

...is represented by the following JRD document:

...次JRDの文書で表されます。

{ "subject":"http://blog.example.com/article/id/314", "expires":"2010-01-30T09:30:00Z",

{ "対象"： "http://blog.example.com/article/id/314"、 "有効期限が切れ"： "2010-01-30T09：30：00Z"、

"aliases":[ "http://blog.example.com/cool_new_thing", "http://blog.example.com/steve/article/7"],

"エイリアス"：[ "http://blog.example.com/cool_new_thing"、 "http://blog.example.com/steve/article/7"]、

"properties":{ "http://blgx.example.net/ns/version":"1.3", "http://blgx.example.net/ns/ext":null },

"プロパティ"：{ "http://blgx.example.net/ns/version":"1.3"、「http://blgx.example.net/ns/ext":null}

"links":[ { "rel":"author", "type":"text/html", "href":"http://blog.example.com/author/steve", "titles":{ "default":"About the Author", "en-us":"Author Information" }, "properties":{ "http://example.com/role":"editor" } }, { "rel":"author", "href":"http://example.com/author/john", "titles":{ "default":"The other author" } }, { "rel":"copyright", "template":"http://example.com/copyright?id={uri}" } ] }

"リンク"：[{ "REL"： "著者"、 "タイプ"： "text / htmlの"、 "HREF"： "http://blog.example.com/author/steve"、 "タイトル"：{ "デフォルト "：" 著者について " "EN-US"： "投稿者の情報"}、 "プロパティ"：{ "http://example.com/role":"editor"}}、{ "REL"："著者」、 "HREF"： "http://example.com/author/john"、 "タイトル"：{ "デフォルト"： "他の作者"}}、{ "REL"： "著作権"、 "テンプレート" "http://example.com/copyright?id={uri}"}]}

Note that the "Subject" and "Alias" elements are NOT RECOMMENDED in the context of host-meta documents, and are included in the example for completeness only.

「件名」と「エイリアス」の要素は、ホスト・メタ文書の文脈では推奨されない、と完全性のみの例に含まれていることに注意してください。

Appendix B. Acknowledgments

付録B.謝辞

The authors would like to acknowledge the contributions of everyone who provided feedback and use cases for this specification -- in particular, Dirk Balfanz, DeWitt Clinton, Eve Maler, Breno de Medeiros, Brad Fitzpatrick, James Manger, Will Norris, Mark Nottingham, John Panzer, Drummond Reed, and Peter Saint-Andre.

具体的には、ディルクBalfanz、デウィットクリントン、イブMALER、Breno・デ・メデイロス、ブラッド・フィッツパトリック、ジェームズ・マネージャ、ウィル・ノリス、マーク・ノッティンガム、ジョン - 著者は、この仕様のためのフィードバックと使用例を提供全員の貢献を認めるしたいと思いますパンツァー、ドラモンド・リード、およびピーターサンタンドレ。

Normative References

引用規格

[OASIS.XRD-1.0] Hammer-Lahav, E., Ed., and W. Norris, Ed., "Extensible Resource Descriptor (XRD) Version 1.0", November 2010, <http://docs.oasis-open.org/xri/xrd/v1.0/xrd-1.0.html>.

[OASIS.XRD-1.0]ハンマー - Lahav、E.、エド、およびW.ノリス、エド、 "拡張可能なリソース記述子（XRD）バージョン1.0"、2010年11月、<のhttp：。。//docs.oasis-open。 ORG / XRI / XRD / v1.0を/ XRD-1.0.html>。

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.

[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、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.、Frystyk、H.、Masinter、L.、リーチ、P.、およびT.バーナーズ - リー、 "ハイパーテキスト転送プロトコル - HTTP / 1.1" 、RFC 2616、1999年6月。

[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.

[RFC2818]レスコラ、E.、 "TLSオーバーHTTP"、RFC 2818、2000年5月。

[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005.

[RFC3986]バーナーズ - リー、T.、フィールディング、R.、およびL. Masinter、 "ユニフォームリソース識別子（URI）：汎用構文"、STD 66、RFC 3986、2005年1月。

[RFC4627] Crockford, D., "The application/json Media Type for JavaScript Object Notation (JSON)", RFC 4627, July 2006.

[RFC4627]クロックフォード、D.、RFC 4627、2006年7月 "JavaScriptのObject Notation（JSON）形式のためのアプリケーション/ JSONのメディアタイプ"。

[RFC5234] Crocker, D., Ed., and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.

"構文仕様のための増大しているBNF：ABNF" [RFC5234]クロッカー、D.、エド、およびP. Overell、。、STD 68、RFC 5234、2008年1月。

[RFC5785] Nottingham, M. and E. Hammer-Lahav, "Defining Well-Known Uniform Resource Identifiers (URIs)", RFC 5785, April 2010.

[RFC5785]ノッティンガム、M.とE.ハンマー - Lahav、 "既知のUniform Resource Identifier（URI）を定義"、RFC 5785、2010年4月。

[RFC5988] Nottingham, M., "Web Linking", RFC 5988, October 2010.

[RFC5988]ノッティンガム、M.、 "ウェブリンク"、RFC 5988、2010年10月。

Authors' Addresses

著者のアドレス

Eran Hammer-Lahav (editor)

エランハンマー - Lahav（編集者）

EMail: eran@hueniverse.com URI: http://hueniverse.com

電子メール：eran@hueniverse.com URI：http://hueniverse.com

Blaine Cook

ブレイン・クック

EMail: romeda@gmail.com URI: http://romeda.org

電子メール：romeda@gmail.com URI：http://romeda.org