RFC 6906 - The 'profile' Link Relation Type 日本語訳

原文URL : https://datatracker.ietf.org/doc/html/rfc6906
タイトル : RFC 6906 - 「プロファイル」リンク関係タイプ
翻訳編集 : 自動生成

[要約] RFC 6906は、プロファイルリンク関係タイプに関する仕様であり、リソースとそのプロファイル間の関係を定義しています。目的は、リソースのプロファイル情報を提供し、クライアントがリソースの意味や使用方法を理解できるようにすることです。

Independent Submission                                          E. Wilde
Request for Comments: 6906                               EMC Corporation
Category: Informational                                       March 2013
ISSN: 2070-1721

The 'profile' Link Relation Type

「プロファイル」リンク関係タイプ

Abstract

概要

This specification defines the 'profile' link relation type that allows resource representations to indicate that they are following one or more profiles. A profile is defined not to alter the semantics of the resource representation itself, but to allow clients to learn about additional semantics (constraints, conventions, extensions) that are associated with the resource representation, in addition to those defined by the media type and possibly other mechanisms.

この仕様は、リソース表現が1つ以上のプロファイルに従っていることを示すことができる「プロファイル」リンク関係タイプを定義します。プロファイルは、リソース表現自体のセマンティクスを変更しないように定義されていますが、メディアタイプによって定義されているものに加えて、リソース表現に関連付けられている追加のセマンティクス（制約、規則、拡張）についてクライアントが学習できるように定義されています。他のメカニズム。

Status of This Memo

本文書の状態

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

このドキュメントはInternet Standards Trackの仕様ではありません。情報提供を目的として公開されています。

This is a contribution to the RFC Series, independently of any other RFC stream. The RFC Editor has chosen to publish this document at its discretion and makes no statement about its value for implementation or deployment. Documents approved for publication by the RFC Editor are not a candidate for any level of Internet Standard; see Section 2 of RFC 5741.

これは、他のRFCストリームとは無関係に、RFCシリーズへの貢献です。 RFCエディターは、このドキュメントを独自の裁量で公開することを選択し、実装または展開に対するその価値については何も述べていません。 RFC Editorによって公開が承認されたドキュメントは、どのレベルのインターネット標準の候補にもなりません。 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/rfc6906.

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

著作権表示

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.

この文書は、BCP 78およびこの文書の発行日に有効なIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。

Table of Contents

   1. Introduction ....................................................2
   2. Terminology .....................................................3
   3. Profiles ........................................................3
      3.1. Profiles and Media Types ...................................4
      3.2. Profile Context ............................................5
   4. IANA Considerations .............................................5
   5. Examples ........................................................6
      5.1. hCard ......................................................6
      5.2. Dublin Core ................................................6
      5.3. Podcasts ...................................................7
   6. Security Considerations .........................................7
   7. Acknowledgements ................................................7
   8. References ......................................................7
      8.1. Normative References .......................................7
      8.2. Informative References .....................................7

1. Introduction

1. はじめに

One of the foundations of the Internet and web architecture is the fact that resource representations communicated through protocols, such as SMTP or HTTP, are labeled with a 'media type', which allows a client to understand at run time what 'type' of resource representation it is handling. Sometimes, it would be useful for servers and clients to include additional information about the nature of the resource. This would allow a client understanding this additional information to react in a way specific to that specialization of the resource, where the specialization can be about constraints, conventions, extensions, or any other aspects that do not alter the basic media type semantics. HTML 4 [HTML401] has such a mechanism built into the language, which is the 'profile' attribute of the 'head' element. However, this mechanism is specific to HTML alone; at the time of writing, it seems as if HTML 5 will drop support for this mechanism entirely.

インターネットやウェブアーキテクチャの基礎の1つは、SMTPやHTTPなどのプロトコルを介して通信されるリソース表現に「メディアタイプ」というラベルが付けられることです。これにより、クライアントは実行時にリソースの「タイプ」を理解できます。取り扱い表現です。場合によっては、サーバーとクライアントがリソースの性質に関する追加情報を含めると便利です。これにより、クライアントはこの追加情報を理解して、リソースの特殊化に固有の方法で反応することができます。特殊化は、制約、規則、拡張、または基本的なメディアタイプのセマンティクスを変更しないその他の側面に関するものです。 HTML 4 [HTML401]には、言語に組み込まれたこのようなメカニズムがあります。これは、「head」要素の「profile」属性です。ただし、このメカニズムはHTMLだけに固有のものです。これを書いている時点では、HTML 5がこのメカニズムのサポートを完全に廃止するようです。

RFC 5988 [RFC5988] "defines a framework for typed links that isn't specific to a particular serialisation or application. It does so by redefining the link relation registry established by Atom to have a broader domain, and adding to it the relations that are defined by HTML."

RFC 5988 [RFC5988]は、特定のシリアル化またはアプリケーションに固有ではない型付きリンクのフレームワークを定義します。これは、より広いドメインを持つようにAtomによって確立されたリンク関係レジストリを再定義し、それに関連する関係を追加することによって行いますHTMLで定義されています。」

This specification registers a 'profile' link relation type according to the rules of RFC 5988 [RFC5988]. Links with this relation type can be used in representations that support typed links as well as in HTTP Link headers. The profile link relation type is independent of the context in which it is used and does not constrain, in any way, the target of the linked URI. In fact, for the purpose of this specification, the target URI does not necessarily have to identify a dereferencable resource (or even use a dereferencable URI scheme). Clients can treat the occurrence of a specific URI in the same way as an XML namespace URI and invoke specific behavior based on the assumption that a specific profile target URI signals that a resource representation follows a specific profile. Note that, at the same time, it is possible for profile target URIs to use dereferencable URIs and to use a representation (which is outside the scope of this specification) that represents the information about the profile in a human- or machine-readable way.

この仕様は、RFC 5988 [RFC5988]の規則に従って「プロファイル」リンク関係タイプを登録します。この関係タイプのリンクは、型付きリンクをサポートする表現およびHTTPリンクヘッダーで使用できます。プロファイルリンク関係タイプは、それが使用されるコンテキストに依存せず、リンクされたURIのターゲットを決して制限しません。実際、この仕様では、ターゲットURIが逆参照可能なリソースを識別する必要はありません（逆参照可能なURIスキームを使用する必要もありません）。クライアントは、特定のURIの発生をXML名前空間URIと同じ方法で処理し、特定のプロファイルターゲットURIがリソース表現が特定のプロファイルに従うことを通知するという仮定に基づいて、特定の動作を呼び出すことができます。同時に、プロファイルターゲットURIが逆参照可能なURIを使用し、人間または機械が読み取り可能な方法でプロファイルに関する情報を表す表現（この仕様の範囲外）を使用できることに注意してください。。

As one example, consider the case of podcasts, where a specific kind of feed uses additional fields for media-related metadata. Using a 'profile' link, it would be easily possible for clients to understand that a specific feed is supposed to be a podcast feed, and that it may contain entries using podcast-specific fields. This may allow a client to behave differently when handling such a feed (such as rendering a podcast-specific UI), even when the current set of entries in the feed may not contain any podcast entries. (Section 5.3 gives more details for this example.)

一例として、特定の種類のフィードがメディア関連のメタデータに追加のフィールドを使用するポッドキャストの場合を考えます。「プロファイル」リンクを使用すると、特定のフィードがポッドキャストフィードであることになっていること、およびポッドキャスト固有のフィールドを使用したエントリが含まれている可能性があることをクライアントが簡単に理解できるようになります。これにより、フィード内の現在のエントリのセットにポッドキャストエントリが含まれていない場合でも、そのようなフィードを処理するとき（ポッドキャスト固有のUIのレンダリングなど）、クライアントの動作が異なる場合があります。（セクション5.3に、この例の詳細が記載されています。）

2. Terminology

2. 用語

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

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

3. Profiles

3. プロフィール

The concept of a profile has no strict definition on the Internet or on the web. For the purpose of this specification, a profile can be described as additional semantics that can be used to process a resource representation, such as constraints, conventions, extensions, or any other aspects that do not alter the basic media type semantics. A profile MUST NOT change the semantics of the resource representation when processed without profile knowledge, so that clients both with and without knowledge of a profiled resource can safely use the same representation. While this specification associates profiles with resource representations, creators and users of profiles MAY define and manage them in a way that allows them to be used across media types; thus, they could be associated with a resource, independent of their representations (i.e., using the same profile URI for different media types). However, such a design is outside of the scope of this specification, and clients SHOULD treat profiles as being associated with a resource representation.

プロファイルの概念には、インターネット上またはWeb上での厳密な定義はありません。この仕様の目的のために、プロファイルは、制約、規則、拡張、または基本的なメディアタイプのセマンティクスを変更しないその他の側面など、リソース表現を処理するために使用できる追加のセマンティクスとして説明できます。プロファイルは、プロファイルの知識なしで処理されたときにリソース表現のセマンティクスを変更してはなりません。そのため、プロファイルされたリソースの知識のあるクライアントとないクライアントの両方が同じ表現を安全に使用できます。この仕様はプロファイルをリソース表現に関連付けますが、プロファイルの作成者とユーザーは、メディアタイプ全体で使用できるようにプロファイルを定義および管理できます。したがって、それらは、それらの表現に関係なく（つまり、異なるメディアタイプに同じプロファイルURIを使用して）リソースに関連付けることができます。ただし、そのような設計はこの仕様の範囲外であり、クライアントはプロファイルをリソース表現に関連付けられているものとして扱う必要があります（SHOULD）。

Profiles can be combined, meaning that a single resource representation can conform to zero or any number of profiles. Depending on the profile support of clients, it is possible that the same resource representation, when linked to a number of profiles, can be processed with different sets of processing rules, based on the profile support of the clients.

プロファイルは組み合わせることができます。つまり、単一のリソース表現がゼロまたは任意の数のプロファイルに準拠できます。クライアントのプロファイルサポートに応じて、同じリソース表現を複数のプロファイルにリンクすると、クライアントのプロファイルサポートに基づいて、異なる処理ルールのセットで処理できる場合があります。

Profiles are identified by URI. However, as is the case with, for example, XML namespace URIs, the URI in this case only serves as an identifier, meaning that the presence of a specific URI has to be sufficient for a client to assert that a resource representation conforms to a profile. Thus, clients SHOULD treat profile URIs as identifiers and not as links, but profiles MAY be defined in a way that the URIs do identify retrievable profile description and thus can be accessed by clients by dereferencing the profile URI. For profiles intended for use in environments where clients may encounter unknown profile URIs, profile maintainers SHOULD consider to make the profile URI dereferencable and provide useful documentation at that URI. The design and representation of such profile descriptions, however, is outside the scope of this specification.

プロファイルはURIで識別されます。ただし、たとえばXML名前空間URIの場合と同様に、この場合のURIは識別子としてのみ機能します。つまり、特定のURIの存在は、クライアントがリソース表現がプロフィール。したがって、クライアントはプロファイルURIをリンクではなく識別子として扱う必要がありますが、URIが取得可能なプロファイルの説明を識別し、プロファイルURIを逆参照することでクライアントからアクセスできるようにプロファイルを定義する必要があります。クライアントが不明なプロファイルURIに遭遇する可能性のある環境での使用を目的としたプロファイルの場合、プロファイル管理者は、プロファイルURIを逆参照可能にし、そのURIで有用なドキュメントを提供することを検討する必要があります。ただし、そのようなプロファイル記述の設計と表現は、この仕様の範囲外です。

3.1. Profiles and Media Types

3.1. プロファイルとメディアタイプ

A media type defines both the semantics and the serialization of a specific type of content. In many cases, media types have some built-in extensibility or openness, so that specific instances of the media type can layer additional semantics on top of the media type's foundation. In this case, a profile is the appropriate mechanism to signal that the original semantics and processing model of the media type still apply, but that an additional processing model can be used to extract additional semantics. This is in contrast to a new media type that, instead of just adding processing rules and semantics defines a complete set of processing rules and semantics in most cases. As an example, XHTML is not a profile of XML but a new media type because it introduces a complete new perspective of the underlying XML structures, and from the XHTML point of view, exposing the raw XML is not all that useful for clients. However, hCard (see Section 5.1) is a profile of (X)HTML because it adds processing rules that allow a client to extract additional semantics from a representation, without changing any of the processing rules and semantics of (X)HTML itself. While the line between a media type and a profile might not always be easy to draw, the intention of profiles is not to replace media types, but to add a more lightweight and runtime-capable mechanism that allows servers and clients to be more explicit in how a specific instance of a media type represents concepts that are not defined by the media type itself, but by additional conventions (the profile processing rules and semantics).

メディアタイプは、特定のタイプのコンテンツのセマンティクスとシリアル化の両方を定義します。多くの場合、メディアタイプには拡張性または開放性が組み込まれているため、メディアタイプの特定のインスタンスは、メディアタイプの基盤の上に追加のセマンティクスを階層化できます。この場合、プロファイルは、メディアタイプの元のセマンティクスと処理モデルが引き続き適用されることを通知する適切なメカニズムですが、追加の処理モデルを使用して追加のセマンティクスを抽出できます。これは、処理ルールとセマンティクスを追加するだけでなく、ほとんどの場合、処理ルールとセマンティクスの完全なセットを定義する新しいメディアタイプとは対照的です。例として、XHTMLはXMLのプロファイルではなく、新しいメディアタイプです。これは、基礎となるXML構造の完全な新しい視点を導入するためです。また、XHTMLの観点から、生のXMLを公開することは、クライアントにとってそれほど有用ではありません。ただし、hCard（セクション5.1を参照）は、（X）HTMLのプロファイルです。これは、クライアントが（X）HTML自体の処理ルールとセマンティクスを変更せずに、表現から追加のセマンティクスを抽出できる処理ルールを追加するためです。メディアタイプとプロファイル間の線を描くのは必ずしも簡単ではないかもしれませんが、プロファイルの目的はメディアタイプを置き換えることではなく、サーバーとクライアントをより明示的にできるようにする、より軽量でランタイム対応のメカニズムを追加することです。メディアタイプの特定のインスタンスが、メディアタイプ自体ではなく、追加の規則（プロファイル処理ルールとセマンティクス）によって定義される概念をどのように表すか。

The objective of profiles is that they allow instances to clearly identify what kind of mechanism they are using for expressing additional semantics, should they follow a well-defined framework for doing so (see Section 5 for examples). While this allows servers and clients to represent the use of profiles, it does not make the profile information visible outside of the representation itself, if the representation is using embedded typed links. For newly defined media types that may be used with profiles, it is therefore recommended that they SHOULD define a media type parameter called 'profile' and specify that this media type parameter follows the semantics of a profile as laid out in this document. This way, clients can use this media type parameter to request a certain profile when interacting, for example, with an HTTP server and setting the Accept header. Representations using a 'profile' media type parameter still SHOULD include that value in the representation using the 'profile' link relation, since the media type label of a representation can easily get lost when it is taken out of its conversational context.

プロファイルの目的は、インスタンスが追加のセマンティクスを表現するために使用しているメカニズムの種類を明確に特定できるようにすることです。これにより、サーバーとクライアントはプロファイルの使用を表すことができますが、表現が埋め込み型付きリンクを使用している場合は、プロファイル情報が表現自体の外部に表示されません。したがって、プロファイルで使用できる新しく定義されたメディアタイプについては、「プロファイル」と呼ばれるメディアタイプパラメータを定義し、このメディアタイプパラメータがこのドキュメントで説明されているプロファイルのセマンティクスに従うことを指定する必要があります。このようにして、クライアントはこのメディアタイプパラメータを使用して、たとえばHTTPサーバーと対話してAcceptヘッダーを設定するときに、特定のプロファイルを要求できます。「プロファイル」メディアタイプパラメータを使用する表現は、「プロファイル」リンク関係を使用する表現にその値を含める必要があります（SHOULD）。表現のメディアタイプラベルは、会話コンテキストから取り出されると簡単に失われる可能性があるためです。

Since a representation can link to more than one profile, the same has to be possible for the corresponding media type parameter (if a media type defines such a parameter). Media types defining a 'profile' parameter SHOULD define it as a whitespace-separated list of profile URIs.

表現は複数のプロファイルにリンクできるため、対応するメディアタイプパラメータについても同じことが可能でなければなりません（メディアタイプがそのようなパラメータを定義している場合）。 'profile'パラメータを定義するメディアタイプは、空白で区切られたプロファイルURIのリストとして定義する必要があります（SHOULD）。

3.2. Profile Context

3.2. プロファイルコンテキスト

Profile links convey information about the use of profiles for a media type. If they are used within a media type, they apply to the context specified by that media type. This means, for example, that profile links in the head element of an HTML document apply to the document as a whole. The context of a profile extends to the scope of where it is being used, which means that profiles used in profile media type parameters (as described in Section 3.1) or used in HTTP Link headers extend to the scope of the protocol in which they are being used.

プロファイルリンクは、メディアタイプのプロファイルの使用に関する情報を伝えます。メディアタイプ内で使用される場合、それらはそのメディアタイプで指定されたコンテキストに適用されます。これは、たとえば、HTMLドキュメントのhead要素のプロファイルリンクがドキュメント全体に適用されることを意味します。プロファイルのコンテキストは、それが使用されている範囲に拡張されます。つまり、プロファイルメディアタイプパラメーターで使用されるプロファイル（セクション3.1で説明）またはHTTPリンクヘッダーで使用されるプロファイルは、それらが使用されるプロトコルのスコープに拡張されます。使用されています。

4. IANA Considerations

4. IANAに関する考慮事項

The link relation type below has been registered by IANA per Section 6.2.1 of RFC 5988 [RFC5988]:

以下のリンク関係タイプは、RFC 5988 [RFC5988]のセクション6.2.1に従ってIANAによって登録されています。

Relation Name: profile

関係名：プロファイル

Description: Identifying that a resource representation conforms to a certain profile, without affecting the non-profile semantics of the resource representation.

説明：リソース表現が非プロファイルセマンティクスに影響を与えることなく、リソース表現が特定のプロファイルに準拠していることを識別します。

Reference: [RFC6906]

参照：[RFC6906]

Notes: Profile URIs are primarily intended to be used as identifiers, and thus clients SHOULD NOT indiscriminately access profile URIs.

注：プロファイルURIは主に識別子として使用することを目的としているため、クライアントは無差別にプロファイルURIにアクセスするべきではありません（SHOULD NOT）。

5. Examples

5. 例

This section lists some examples of profiles that are already defined (and thus could be readily used with a 'profile' link) and of some potential additional profiles. So far, profiles have been mostly limited to HTML (because of the support of profiles in HTML). The two examples of existing profiles are HTML profiles, and the one hypothetical example is a non-HTML example that is based on feeds.

このセクションでは、既に定義されている（したがって、「プロファイル」リンクですぐに使用できる）プロファイルと、いくつかの潜在的な追加プロファイルの例を示します。これまでのところ、プロファイルは主にHTMLに制限されていました（HTMLでのプロファイルのサポートのため）。既存のプロファイルの2つの例はHTMLプロファイルで、1つの架空の例はフィードに基づく非HTMLの例です。

5.1. hCard

The hCard profile uses http://microformats.org/profile/hcard as its defining URI and is essentially a mechanism on how vCard [RFC6350] information can be embedded in an HTML page using the mechanisms provided by microformats. It is thus a good example for how profiles might, on the one hand, define a model-based extension of the original media type (in this case, adding vCard fields), and how they also have to define specific ways of how that model extension is then represented in the media type (in this case, using microformats). Alternatively, it would be possible to represent vCard information through the mechanisms of RDF in Attributes (RDFa) or microdata, but since these would be different conventions that a client would need to follow to extract the vCard data, they would be identified by different profiles.

hCardプロファイルは、その定義URIとしてhttp://microformats.org/profile/hcardを使用し、本質的に、microformatsが提供するメカニズムを使用して、vCard [RFC6350]情報をHTMLページに埋め込む方法に関するメカニズムです。したがって、これは、一方でプロファイルが元のメディアタイプのモデルベースの拡張を定義する方法（この場合はvCardフィールドを追加する方法）と、モデルがどのように特定の方法を定義する必要があるかを示す良い例です拡張子はメディアタイプで表されます（この場合、microformatsを使用）。あるいは、RDFの属性（RDFa）またはmicrodataのメカニズムを介してvCard情報を表すことが可能ですが、これらはvCardデータを抽出するためにクライアントが従う必要のある異なる規則であるため、異なるプロファイルによって識別されます。。

5.2. Dublin Core

5.2. ダブリンコア

Dublin Core metadata identified by the profile http://dublincore.org/documents/2008/08/04/dc-html/ can be used to embed Dublin Core metadata in an HTML page. In contrast to hCard, which uses microformats as its foundation, the Dublin Core profile defines its own way of embedding metadata into HTML, and it does so using HTML <link> elements. The interesting difference to hCard is that Dublin Core not only defines metadata to be embedded in HTML, it also allows links to be added as metadata. In which case, the profile not only describes additional data to be found within the representation, but also allows the representation to be linked to additional resources.

プロファイルhttp://dublincore.org/documents/2008/08/04/dc-html/で識別されるダブリンコアメタデータを使用して、ダブリンコアメタデータをHTMLページに埋め込むことができます。基盤としてマイクロフォーマットを使用するhCardとは対照的に、ダブリンコアプロファイルは、メタデータをHTMLに埋め込む独自の方法を定義し、HTMLの<link>要素を使用してそのようにします。 hCardとの興味深い違いは、ダブリンコアはメタデータをHTMLに埋め込むように定義するだけでなく、リンクをメタデータとして追加できることです。この場合、プロファイルは、表現内で検出される追加のデータを記述するだけでなく、表現を追加のリソースにリンクすることもできます。

5.3. Podcasts

5.3. ポッドキャスト

Podcasts are an extension of feed formats and define a substantial set of additional attributes to reflect the fact that the resources in podcast feeds are time-based media formats, such as audio and video. While there is no profile URI for podcasts, the current definition (maintained by Apple) at http://www.apple.com/itunes/podcasts/specs.html could serve as such a URI, or it could by updated to include such a URI. Podcasts are feeds with special behavior; and while it is possible to follow a podcast feed using a generic feed reader, a podcast-aware feed reader will be able to extract additional information from the feed, and thus can implement more sophisticated services or present a more sophisticated UI for podcast feeds. The Apple page referenced above describes the implementation of one such specialized podcast feed reader, Apple iTunes.

ポッドキャストはフィード形式の拡張であり、ポッドキャストフィードのリソースがオーディオやビデオなどの時間ベースのメディア形式であることを反映するために、追加の属性の実質的なセットを定義します。ポッドキャストのプロファイルURIはありませんが、http：//www.apple.com/itunes/podcasts/specs.htmlでの現在の定義（Appleが管理）がそのようなURIとして機能するか、またはそのようなURIを含めるように更新することができますURI。ポッドキャストは特別な動作を持つフィードです。また、汎用フィードリーダーを使用してポッドキャストフィードをフォローすることは可能ですが、ポッドキャスト対応フィードリーダーはフィードから追加情報を抽出できるため、より高度なサービスを実装したり、ポッドキャストフィードのより高度なUIを表示したりできます。上で参照したアップルのページでは、そのような特殊なポッドキャストフィードリーダーであるApple iTunesの実装について説明しています。

6. Security Considerations

6. セキュリティに関する考慮事項

The 'profile' relation type is not known to introduce any new security issues not already discussed in RFC 5988 [RFC5988] for generic use of Web linking mechanisms.

'profile'関係タイプは、RFC 5988 [RFC5988]でまだ説明されていない新しいセキュリティ問題をWebリンクメカニズムの一般的な使用に導入することは知られていません。

7. Acknowledgements

7. 謝辞

Thanks for comments and suggestions provided by Erlend Hamnaberg, Markus Lanthaler, Simon Mayer, Mark Nottingham, Julian Reschke, James Snell, Herbert Van de Sompel, and Tim Williams.

Erlend Hamnaberg、Markus Lanthaler、Simon Mayer、Mark Nottingham、Julian Reschke、James Snell、Herbert Van de Sompel、Tim Williamsからのコメントと提案に感謝します。

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, March 1997.

[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、1997年3月。

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

[RFC5988]ノッティンガム、M。、「Webリンク」、RFC 5988、2010年10月。

8.2. Informative References

8.2. 参考引用

[HTML401] Le Hors, A., Raggett, D., 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>.

[HTML401] Le Hors、A.、Raggett、D。、および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>。

[RFC6350] Perreault, S., "vCard Format Specification", RFC 6350, August 2011.

[RFC6350] Perreault、S。、「vCard Format Specification」、RFC 6350、2011年8月。

Author's Address

著者のアドレス

Erik Wilde EMC Corporation 6801 Koll Center Parkway Pleasanton, CA 94566 U.S.A.

Erik Wilde EMC Corporation 6801 Koll Center Parkway Pleasanton、CA 94566 U.S.A.

   Phone: +1-925-6006244
   EMail: erik.wilde@emc.com
   URI:   http://dret.net/netdret/