RFC 8631 - Link Relation Types for Web Services 日本語訳

原文URL : https://datatracker.ietf.org/doc/html/rfc8631
タイトル : RFC 8631 - Webサービスのリンク関係タイプ
翻訳編集 : 自動生成

[要約] RFC 8631は、Webサービスのリンク関係タイプに関する規格であり、Webサービス間の関連性を表現するためのリンクタイプを定義しています。その目的は、Webサービスの相互運用性と検索可能性を向上させることです。

Internet Engineering Task Force (IETF)                          E. Wilde
Request for Comments: 8631                                     July 2019
Category: Informational
ISSN: 2070-1721

Link Relation Types for Web Services

Webサービスのリンク関係タイプ

Abstract

概要

Many resources provided on the Web are part of sets of resources that are provided in a context that is managed by one particular service provider. Often, these sets of resources are referred to as "Web services" or "Web APIs". This specification defines link relations that represent relationships from Web services or APIs to resources that provide documentation, descriptions, metadata, or status information for these resources. Documentation is primarily intended for human consumers, whereas descriptions are primarily intended for automated consumers. Metadata provides information about a service's context. This specification also defines a link relation to identify status resources that are used to represent information about service status.

Webで提供される多くのリソースは、1つの特定のサービスプロバイダーによって管理されるコンテキストで提供されるリソースセットの一部です。多くの場合、これらのリソースのセットは「Webサービス」または「Web API」と呼ばれます。この仕様は、WebサービスまたはAPIから、ドキュメント、説明、メタデータ、またはこれらのリソースのステータス情報を提供するリソースへの関係を表すリンク関係を定義します。ドキュメントは主に人間の消費者を対象としていますが、説明は主に自動化された消費者を対象としています。メタデータは、サービスのコンテキストに関する情報を提供します。この仕様は、サービスのステータスに関する情報を表すために使用されるステータスリソースを識別するためのリンク関係も定義します。

Status of This Memo

本文書の状態

This document is not an Internet Standards Track specification; it is published for informational purposes.

このドキュメントは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). Not all documents approved by the IESG are candidates for any level of Internet Standard; see Section 2 of RFC 7841.

このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。 IESGによって承認されたすべてのドキュメントが、あらゆるレベルのインターネット標準の候補であるとは限りません。 RFC 7841のセクション2をご覧ください。

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

このドキュメントの現在のステータス、エラッタ、およびフィードバックの提供方法に関する情報は、https：//www.rfc-editor.org/info/rfc8631で入手できます。

著作権表示

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://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トラストの法的規定（https://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   4
   3.  Web Services  . . . . . . . . . . . . . . . . . . . . . . . .   4
     3.1.  Documenting Web Services  . . . . . . . . . . . . . . . .   5
     3.2.  Describing Web Services . . . . . . . . . . . . . . . . .   5
     3.3.  Unified Documentation/Description . . . . . . . . . . . .   5
   4.  Link Relations for Web Services . . . . . . . . . . . . . . .   5
     4.1.  The service-doc Link Relation Type  . . . . . . . . . . .   6
     4.2.  The service-desc Link Relation Type . . . . . . . . . . .   6
     4.3.  The service-meta Link Relation Type . . . . . . . . . . .   6
   5.  Web Service Status Resources  . . . . . . . . . . . . . . . .   7
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   7
     6.1.  Link Relation Type: service-doc . . . . . . . . . . . . .   7
     6.2.  Link Relation Type: service-desc  . . . . . . . . . . . .   7
     6.3.  Link Relation Type: service-meta  . . . . . . . . . . . .   8
     6.4.  Link Relation Type: status  . . . . . . . . . . . . . . .   8
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .   8
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   9
     8.1.  Normative References  . . . . . . . . . . . . . . . . . .   9
     8.2.  Informative References  . . . . . . . . . . . . . . . . .   9
   Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .   9
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .   9

1. Introduction

1. はじめに

One of the defining aspects of the Web is that it is possible to interact with Web resources without any prior knowledge of the specifics of the resource. Following the practices described in Web architecture [W3C.REC-webarch-20041215] by using URIs, HTTP, and media types, the Web's uniform interface allows interactions with resources without the more complex binding procedures often necessary with other approaches.

Webを定義する側面の1つは、リソースの詳細について事前の知識がなくてもWebリソースと対話できることです。 Webアーキテクチャ[W3C.REC-webarch-20041215]で説明されているプラクティスに従って、URI、HTTP、およびメディアタイプを使用することで、Webの統一されたインターフェースにより、他のアプローチでしばしば必要となるより複雑なバインディング手順なしでリソースとの相互作用が可能になります。

Many resources on the Web are provided as part of a set of resources that are referred to as a "Web service" or a "Web API". In many cases, these services or APIs are defined and managed as a whole, and it may be desirable for clients to be able to discover this service information.

Web上の多くのリソースは、「Webサービス」または「Web API」と呼ばれる一連のリソースの一部として提供されます。多くの場合、これらのサービスまたはAPIは全体として定義および管理されており、クライアントがこのサービス情報を検出できることが望ましい場合があります。

Service information that provides information on how to use service resources can be broadly separated into two categories: One category primarily targets human users and often uses generic representations for human readable documents, such as HTML or PDF. The other category is structured information that follows a more formalized description model and is primarily intended for consumption by machines -- for example, tools and code libraries.

サービスリソースの使用方法に関する情報を提供するサービス情報は、大きく2つのカテゴリに分けることができます。1つのカテゴリは主に人間のユーザーを対象とし、HTMLやPDFなどの人間が読めるドキュメントの一般的な表現を使用することがよくあります。もう1つのカテゴリは、より形式化された記述モデルに従う構造化情報であり、主に、ツールやコードライブラリなどのマシンによる消費を目的としています。

In the context of this memo, the human-oriented variant is referred to as "documentation", and the machine-oriented variant is referred to as "description".

このメモのコンテキストでは、人間指向のバリアントは「ドキュメント」と呼ばれ、機械指向のバリアントは「説明」と呼ばれます。

These two categories are not necessarily mutually exclusive, as representations have been proposed that are intended for both human consumption and interpretation by machine clients. In addition, a typical pattern for service documentation/descriptions is that there is human-oriented, high-level documentation that is intended to put a service in context and explain the general model, which is complemented by machine-level descriptions that are intended as detailed technical descriptions of the service. These two resources could be interlinked, but since they are intended for different audiences, it can make sense to provide entry points for both of them.

人間による消費とマシンクライアントによる解釈の両方を目的とした表現が提案されているため、これら2つのカテゴリは必ずしも相互に排他的ではありません。さらに、サービスのドキュメント/説明の典型的なパターンは、サービスを状況に合わせて一般的なモデルを説明することを目的とした人間指向の高レベルのドキュメントが存在することです。サービスの詳細な技術説明。これらの2つのリソースは相互にリンクできますが、それらは異なる対象ユーザーを対象としているため、両方にエントリポイントを提供することは理にかなっています。

In addition, while both documentation and descriptions may be provided as part of a Web service, there may be other information as well. Generally speaking, a Web service may have any metadata/ resources associated with it (with documentation and descriptions being two specific kinds of resources). If there is a way in which all of these metadata/resources can be represented, then it should be possible to find such a resource that provides access to general Web service metadata.

さらに、ドキュメントと説明の両方がWebサービスの一部として提供される場合がありますが、他の情報も存在する場合があります。一般的に言えば、Webサービスにはメタデータ/リソースが関連付けられている場合があります（ドキュメントと説明は2つの特定の種類のリソースです）。これらすべてのメタデータ/リソースを表現できる方法があれば、一般的なWebサービスメタデータへのアクセスを提供するリソースを見つけることができるはずです。

In addition to these resources about mostly static aspects of a Web service, this memo also defines a link relation that allows providers of a Web service to link to a resource that represents status information about the service. This information often represents operational information that allows service consumers to retrieve information about "service health" and related issues.

Webサービスのほとんど静的な側面に関するこれらのリソースに加えて、このメモは、Webサービスのプロバイダーがサービスに関するステータス情報を表すリソースにリンクできるようにするリンク関係も定義します。この情報は多くの場合、サービスの利用者が「サービスの健全性」および関連する問題に関する情報を取得できるようにする運用情報を表します。

This memo places no constraints on the specific representations used for all of these resources. It simply allows providers of a Web service to make the documentation, descriptions, metadata, and status of their services discoverable and defines link relations that serve that purpose.

このメモは、これらすべてのリソースに使用される特定の表現に制約を課しません。それは単に、Webサービスのプロバイダーがサービスのドキュメント、説明、メタデータ、およびステータスを検出できるようにし、その目的に役立つリンク関係を定義することを可能にします。

2. Terminology

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 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.

キーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、「OPTIONALこのドキュメントの「」は、BCP 14 [RFC2119] [RFC8174]で説明されているように解釈されます。

3. Web Services

3. ウェブサービス

"Web Services" or "Web APIs" (sometimes also referred to as "HTTP API" or "REST API") expose information and services on the Web. Following the principles of Web architecture [W3C.REC-webarch-20041215], they expose URI-identified resources, which are then accessed and transferred using a specific representation. Many services use representations that contain links, and these links are often typed links.

「Webサービス」または「Web API」（「HTTP API」または「REST API」とも呼ばれる）は、Web上の情報とサービスを公開します。 Webアーキテクチャの原則[W3C.REC-webarch-20041215]に従い、URIで識別されるリソースを公開し、特定の表現を使用してアクセスおよび転送されます。多くのサービスはリンクを含む表現を使用し、これらのリンクは多くの場合型付きリンクです。

Using typed links, resources can identify relationship types to other resources. RFC 8288 [RFC8288] establishes a framework of registered link relation types, which are identified by simple strings and registered in an IANA registry. Any resource that supports typed links according to RFC 8288 can then use these identifiers to represent resource relationships on the Web without having to reinvent registered relation types.

型付きリンクを使用すると、リソースは他のリソースとの関係タイプを識別できます。 RFC 8288 [RFC8288]は、登録されたリンク関係タイプのフレームワークを確立します。これは、単純な文字列によって識別され、IANAレジストリに登録されます。 RFC 8288に従って型付きリンクをサポートするすべてのリソースは、これらの識別子を使用して、登録された関係タイプを再発明することなく、Web上のリソース関係を表すことができます。

In recent years, Web services, as well as their documentation and description languages, have gained popularity due to the general popularity of the Web as a platform for providing information and services. However, the design of documentation and description languages varies according to a number of factors, such as the general application domain, the preferred application data model, and the preferred approach for exposing services.

近年、情報およびサービスを提供するためのプラットフォームとしてのWebの一般的な人気により、Webサービス、およびそのドキュメントと説明言語が人気を博しています。ただし、ドキュメントと記述言語のデザインは、一般的なアプリケーションドメイン、推奨されるアプリケーションデータモデル、サービスを公開するための推奨されるアプローチなど、いくつかの要因によって異なります。

This specification allows service providers to use a unified method to link to service documentation and/or descriptions. This link should not make any assumptions about the provided type of documentation and/or descriptions, so service providers can choose those that best fit their services and needs.

この仕様により、サービスプロバイダーは統一された方法を使用して、サービスのドキュメントや説明にリンクできます。このリンクでは、提供されるドキュメントや説明の種類について何も想定しないでください。サービスプロバイダーは、サービスやニーズに最適なものを選択できます。

This specification also allows service providers to link to general service metadata. One part of the metadata may have links to documentation and/or description as well as other information about a service, such as deployment or operational information.

この仕様により、サービスプロバイダーは一般的なサービスメタデータにリンクすることもできます。メタデータの一部には、ドキュメントや説明、および展開や運用情報などのサービスに関するその他の情報へのリンクが含まれる場合があります。

3.1. Documenting Web Services

3.1. Webサービスの文書化

In the context of this specification, "documentation" refers to information that is primarily intended for human consumption. Typical representations of this kind of documentation are HTML and PDF.

この仕様のコンテキストでは、「ドキュメント」は主に人間による消費を目的とした情報を指します。この種のドキュメントの典型的な表現は、HTMLとPDFです。

Documentation is often structured, but its structure depends on the structure of the service in question as well as the specific way in which the authors choose to present it.

ドキュメントはしばしば構造化されていますが、その構造は、問題のサービスの構造と、作成者がそれを提示することを選択した特定の方法に依存します。

3.2. Describing Web Services

3.2. Webサービスの説明

In the context of this specification, "description" refers to information that is primarily intended for machine consumption. Typical representations are dictated by the technology underlying the service itself, which means that description formats in today's technology landscape are based on XML, JSON, Resource Description Framework (RDF), and a variety of other structured data models. In each of those technologies, there may be a variety of languages defined to serve the same general purpose of describing a Web service.

この仕様のコンテキストでは、「説明」は主にマシンの消費を目的とした情報を指します。一般的な表現は、サービス自体の基礎となるテクノロジーによって決定されます。つまり、今日のテクノロジーランドスケープの記述形式は、XML、JSON、Resource Description Framework（RDF）、およびその他のさまざまな構造化データモデルに基づいています。これらの各テクノロジでは、Webサービスを記述するという同じ一般的な目的を果たすために定義されたさまざまな言語が存在する場合があります。

Descriptions are always structured, but the structuring principles depend on the nature of the described service. For example, one of the earlier service description approaches, the Web Services Description Language (WSDL), uses "operations" as its core concept, which are essentially identical to function calls because the underlying model is based on the Remote Procedure Call (RPC) model. Other description languages for non-RPC approaches to services will use different structuring approaches, such as structuring service descriptions by URIs and/or URI patterns.

説明は常に構造化されていますが、構造化の原則は、記述されたサービスの性質によって異なります。たとえば、以前のサービス記述アプローチの1つであるWebサービス記述言語（WSDL）では、基本的なモデルがリモートプロシージャコール（RPC）に基づいているため、基本的に関数呼び出しと同じ「操作」をコアコンセプトとして使用します。モデル。サービスへの非RPCアプローチの他の記述言語は、URIやURIパターンによるサービス記述の構造化など、さまざまな構造化アプローチを使用します。

3.3. Unified Documentation/Description

3.3. 統一されたドキュメント/説明

If service providers use an approach where there is no distinction between service documentation (Section 3.1) and service description (Section 3.2), then they may not feel the need to use two separate links. In such a case, an alternative approach is to use the previously defined "service" link relation type [RFC5023], which does not indicate whether it links to documentation or description and thus may be a better fit if no such differentiation is required.

サービスプロバイダーがサービスドキュメント（セクション3.1）とサービスの説明（セクション3.2）の間に区別がないアプローチを使用する場合、2つの別々のリンクを使用する必要性を感じない場合があります。そのような場合、代替のアプローチは、以前に定義された「サービス」リンク関係タイプ[RFC5023]を使用することです。これは、ドキュメントまたは説明にリンクするかどうかを示さないため、そのような区別が必要ない場合により適しています。

4. Link Relations for Web Services

4. Webサービスのリンク関係

In order to allow Web services to represent the relation of individual resources to service documentation/description and metadata, this specification introduces and registers three new link relation types.

Webサービスが個々のリソースとサービスのドキュメント/説明およびメタデータとの関係を表すことができるようにするために、この仕様では3つの新しいリンク関係タイプを導入および登録しています。

4.1. The service-doc Link Relation Type

4.1. service-docリンク関係タイプ

The "service-doc" link relation type is used to represent the fact that a resource or a set of resources is documented at a specific URI. The target resource is expected to provide documentation that is primarily intended for human consumption.

「service-doc」リンク関係タイプは、リソースまたはリソースのセットが特定のURIで文書化されているという事実を表すために使用されます。ターゲットリソースは、主に人間による消費を目的としたドキュメントを提供することが期待されています。

4.2. The service-desc Link Relation Type

4.2. service-descリンク関係タイプ

The "service-desc" link relation type is used to represent the fact that a resource or a set of resources is described at a specific URI. The target resource is expected to provide a service description that is primarily intended for machine consumption. In many cases, it is provided in a representation that is consumed by tools, code libraries, or similar components.

「service-desc」リンク関係タイプは、リソースまたはリソースのセットが特定のURIで記述されているという事実を表すために使用されます。ターゲットリソースは、主にマシンの消費を目的としたサービスの説明を提供することが期待されています。多くの場合、ツール、コードライブラリ、または類似のコンポーネントによって使用される表現で提供されます。

4.3. The service-meta Link Relation Type

4.3. サービスとメタのリンク関係タイプ

The "service-meta" link relation type is used to link to available metadata for the service context of a resource. Service metadata is any kind of data that may be of interest to existing or potential service users, with documentation/description being only two possible facets of service metadata. The target resource is expected to provide a representation that is primarily intended for machine consumption. In many cases, it is provided in a representation that is consumed by tools, code libraries, or similar components.

「service-meta」リンク関係タイプは、リソースのサービスコンテキストで使用可能なメタデータにリンクするために使用されます。サービスメタデータは、既存または潜在的なサービスユーザーが関心を持つ可能性のあるあらゆる種類のデータであり、ドキュメント/説明はサービスメタデータの2つの可能性のある側面にすぎません。ターゲットリソースは、主にマシンの消費を目的とした表現を提供することが期待されています。多くの場合、ツール、コードライブラリ、または類似のコンポーネントによって使用される表現で提供されます。

Since service metadata can have many different purposes and use many different representations, it may make sense for representations using the "service-meta" link relation to offer additional hints about the specific kind or format of metadata that is being linked.

サービスメタデータにはさまざまな目的があり、さまざまな表現を使用できるため、「service-meta」リンク関係を使用する表現では、リンクされているメタデータの特定の種類または形式に関する追加のヒントを提供することが理にかなっています。

This definition of the "service-meta" link relation makes no specific assumptions about how these link hints will be represented, and the specific mechanism will depend on the context where the "service-meta" link relation is being used.

「service-meta」リンク関係のこの定義は、これらのリンクヒントがどのように表現されるかについて特定の仮定を行わず、特定のメカニズムは「service-meta」リンク関係が使用されているコンテキストに依存します。

One example is that a "service-desc" link may identify an OpenAPI description, which is supposed to be the machine-readable description of a Web API. A "service-meta" link may identify a resource that contains additional metadata about the Web API, such as labels that classify the API according to a labeling scheme and a privacy policy that makes statements about how the Web API manages personally identifiable information.

1つの例は、「service-desc」リンクがOpenAPIの説明を識別できることです。これは、Web APIの機械可読な説明であると想定されています。「service-meta」リンクは、ラベル付けスキームに従ってAPIを分類するラベルや、Web APIが個人を特定できる情報を管理する方法についてステートメントを作成するプライバシーポリシーなど、Web APIに関する追加のメタデータを含むリソースを識別します。

5. Web Service Status Resources

5. Webサービスステータスリソース

Web services providing access to one or more resources often are hosted and operated in an environment for which status information may be available. This information may be as simple as confirming that a service is operational, or it may provide additional information about different aspects of a service and/or a history of status information, possibly listing incidents and their resolution.

1つまたは複数のリソースへのアクセスを提供するWebサービスは、多くの場合、ステータス情報が利用可能な環境でホストおよび運用されます。この情報は、サービスが動作していることを確認するのと同じくらい簡単な場合もあれば、サービスのさまざまな側面やステータス情報の履歴に関する追加情報を提供し、インシデントとその解決策をリストする場合もあります。

The "status" link relation type can be used to link to such a status resource, allowing service consumers to retrieve information about a Web service's status. Such a link may not be available for and from all resources provided by a Web service -- only from key resources such as a Web service's metadata resource and/or a service's home resource (i.e., a resource analogous to the home page of a Web site).

"status"リンクリレーションタイプを使用して、そのようなステータスリソースにリンクできるため、サービスユーザーはWebサービスのステータスに関する情報を取得できます。このようなリンクは、Webサービスによって提供されるすべてのリソースに対して利用できるわけではありません。Webサービスのメタデータリソースやサービスのホームリソース（つまり、Webのホームページに類似したリソース）などの主要なリソースからのみ利用できます。地点）。

This memo does not restrict the representation of a status resource in any way. It may be primarily focused on human or machine consumption or a combination of both. It may be a simple "traffic light" indicator for service health or a more sophisticated representation conveying more detailed information, such as service subsystems and/or a status history.

このメモは、ステータスリソースの表現を決して制限しません。それは主に人間や機械の消費、またはその両方の組み合わせに焦点を当てている可能性があります。これは、サービスヘルスの単純な「信号」インジケータ、またはサービスサブシステムやステータス履歴などのより詳細な情報を伝えるより洗練された表現の場合があります。

6. IANA Considerations

Webサービスプロバイダーのもう1つの潜在的なセキュリティの問題は、サービスの説明とドキュメントを公開すると、通常、クライアント（悪意のあるものもそうでないものも）がサービスへのより自動化された体系的なアクセスを許可することです。したがって、サービスの潜在的な脆弱性の多くが発見および悪用されやすくなるか、またはサービスが自動クライアントによってアクセスされるため、サービスがより多くの負荷を受け取る可能性があります。

Web service consumers should be aware that service descriptions and documentation can be out of sync or simply incorrect. Blindly trusting service descriptions and documentation (particularly when descriptions are retrieved and interpreted programmatically) is not a safe practice. Web service consumers SHOULD always assume that service descriptions and documentation may be incorrect and SHOULD therefore be prepared to handle errors at runtime.

Webサービスの利用者は、サービスの説明とドキュメントが同期していないか、単に正しくない場合があることを認識しておく必要があります。サービスの説明とドキュメントを盲目的に信頼すること（特に、説明が取得されてプログラムで解釈される場合）は安全な方法ではありません。 Webサービスの利用者は、サービスの説明とドキュメントが正しくない可能性があることを常に想定している必要があるため、実行時にエラーを処理する準備をする必要があります。

8. References

8. 参考文献

8.1. Normative References

8.1. 引用文献

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.

[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<https://www.rfc-editor.org/info/ rfc2119>。

[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.

[RFC8174] Leiba、B。、「RFC 2119キーワードの大文字と小文字のあいまいさ」、BCP 14、RFC 8174、DOI 10.17487 / RFC8174、2017年5月、<https://www.rfc-editor.org/info/ rfc8174>。

[RFC8288] Nottingham, M., "Web Linking", RFC 8288, DOI 10.17487/RFC8288, October 2017, <https://www.rfc-editor.org/info/rfc8288>.

[RFC8288]ノッティンガム、M。、「Webリンク」、RFC 8288、DOI 10.17487 / RFC8288、2017年10月、<https://www.rfc-editor.org/info/rfc8288>。

8.2. Informative References

8.2. 参考引用

[RFC5023] Gregorio, J., Ed. and B. de hOra, Ed., "The Atom Publishing Protocol", RFC 5023, DOI 10.17487/RFC5023, October 2007, <https://www.rfc-editor.org/info/rfc5023>.

[RFC5023]グレゴリオ、J、エド。 B. de hOra編、「The Atom Publishing Protocol」、RFC 5023、DOI 10.17487 / RFC5023、2007年10月、<https://www.rfc-editor.org/info/rfc5023>。

[W3C.REC-webarch-20041215] Jacobs, I. and N. Walsh, "Architecture of the World Wide Web, Volume One", World Wide Web Consortium Recommendation REC-webarch-20041215, December 2004, <http://www.w3.org/TR/2004/REC-webarch-20041215>.

[W3C.REC-webarch-20041215] Jacobs、I.およびN. Walsh、「Architecture of the World Wide Web、Volume One」、World Wide Web Consortium Recommendation REC-webarch-20041215、2004年12月、<http：// www .w3.org / TR / 2004 / REC-webarch-20041215>。

Acknowledgements

謝辞

Thanks to Mike Amundsen, Ben Campbell, Alissa Cooper, Oliver Gierke, Benjamin Kaduk, Sebastien Lambla, Darrell Miller, and Adam Roach for their comments and suggestions.

コメントと提案をしてくれたMike Amundsen、Ben Campbell、Alissa Cooper、Oliver Gierke、Benjamin Kaduk、Sebastien Lambla、Darrell Miller、Adam Roachに感謝します。

Author's Address

著者のアドレス

Erik Wilde

エリック・ワイルド

   Email: erik.wilde@dret.net
   URI:   http://dret.net/netdret/