[要約] RFC 5988は、Webリンクの標準化に関するドキュメントであり、リソース間の関係を表現するためのリンクヘッダーの形式を定義しています。その目的は、Webアプリケーションの相互運用性を向上させ、リソースの発見とナビゲーションを容易にすることです。
Internet Engineering Task Force (IETF) M. Nottingham
Request for Comments: 5988 October 2010
Updates: 4287
Category: Standards Track
ISSN: 2070-1721
Web Linking
ウェブリンク
Abstract
概要
This document specifies relation types for Web links, and defines a registry for them. It also defines the use of such links in HTTP headers with the Link header field.
このドキュメントでは、Webリンクの関係タイプを指定し、それらのレジストリを定義します。また、リンクヘッダーフィールドを使用して、HTTPヘッダーでのこのようなリンクの使用を定義します。
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/rfc5988.
このドキュメントの現在のステータス、正誤表、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc5988で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2010 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に記載されているように保証なしで提供されます。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
このドキュメントには、2008年11月10日より前に公開または公開されたIETFドキュメントまたはIETFコントリビューションの素材が含まれている場合があります。この素材の一部の著作権を管理する人は、IETFトラストにそのような素材の変更を許可する権利を付与していない可能性がありますIETF標準プロセス外。このような資料の著作権を管理する人から適切なライセンスを取得しない限り、このドキュメントはIETF標準プロセス外で変更できません。また、その派生物は、IETF標準プロセス外で作成できません。 RFCとして、またはそれを英語以外の言語に翻訳するための出版物。
Table of Contents
目次
1. Introduction ....................................................3
2. Notational Conventions ..........................................3
3. Links ...........................................................4
4. Link Relation Types .............................................5
4.1. Registered Relation Types ..................................5
4.2. Extension Relation Types ...................................6
5. The Link Header Field ...........................................6
5.1. Target IRI .................................................7
5.2. Context IRI ................................................7
5.3. Relation Type ..............................................8
5.4. Target Attributes ..........................................8
5.5. Examples ...................................................9
6. IANA Considerations ............................................10
6.1. Link HTTP Header Registration .............................10
6.2. Link Relation Type Registry ...............................10
6.2.1. Registering New Link Relation Types ................11
6.2.2. Initial Registry Contents ..........................12
6.3. Link Relation Application Data Registry ...................16
7. Security Considerations ........................................17
8. Internationalisation Considerations ............................18
9. References .....................................................18
9.1. Normative References ......................................18
9.2. Informative References ....................................19
Appendix A. Notes on Using the Link Header with the HTML4
Format ...............................................21
Appendix B. Notes on Using the Link Header with the Atom
Format ...............................................22
Appendix C. Acknowledgements .....................................23
A means of indicating the relationships between resources on the Web, as well as indicating the type of those relationships, has been available for some time in HTML [W3C.REC-html401-19991224], and more recently in Atom [RFC4287]. These mechanisms, although conceptually similar, are separately specified. However, links between resources need not be format specific; it can be useful to have typed links that are independent of their serialisation, especially when a resource has representations in multiple formats.
Web上のリソース間の関係とそれらの関係のタイプを示す手段は、しばらくの間HTML [W3C.REC-html401-19991224]で、そして最近ではAtom [RFC4287]で利用可能になりました。これらのメカニズムは、概念的には類似していますが、個別に指定されています。ただし、リソース間のリンクはフォーマット固有である必要はありません。特にリソースが複数の形式で表現されている場合は、シリアル化に依存しない型付きリンクを使用すると便利です。
To this end, this document 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.
この目的のために、このドキュメントでは、特定のシリアル化またはアプリケーションに固有ではない、型付きリンクのフレームワークを定義しています。これは、Atomによって確立されたリンク関係レジストリーをより広いドメインを持つように再定義し、それにHTMLによって定義された関係を追加することによって行われます。
Furthermore, an HTTP header field for conveying typed links was defined in Section 19.6.2.4 of [RFC2068], but removed from [RFC2616], due to a lack of implementation experience. Since then, it has been implemented in some User Agents (e.g., for stylesheets), and several additional use cases have surfaced.
さらに、型付きリンクを伝達するためのHTTPヘッダーフィールドは[RFC2068]のセクション19.6.2.4で定義されていましたが、実装の経験がないため[RFC2616]から削除されました。それ以来、一部のユーザーエージェント（スタイルシートなど）に実装され、いくつかの追加のユースケースが明らかになりました。
Because it was removed, the status of the Link header is unclear, leading some to consider minting new application-specific HTTP headers instead of reusing it. This document addresses this by re-specifying the Link header as one such serialisation, with updated but backwards-compatible syntax.
削除されたため、Linkヘッダーのステータスは不明確で、新しいアプリケーション固有のHTTPヘッダーを再利用するのではなく、作成することを検討する人もいます。このドキュメントでは、更新された下位互換性のある構文を使用して、Linkヘッダーをそのようなシリアル化の1つとして再指定することで、この問題に対処します。
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 BCP 14, [RFC2119], as scoped to those conformance targets.
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 BCP 14 [RFC2119]で説明されているように解釈され、それらの適合ターゲットにスコープされます。
This document uses the Augmented Backus-Naur Form (ABNF) notation of [RFC2616], and explicitly includes the following rules from it: quoted-string, token, SP (space), LOALPHA, DIGIT.
このドキュメントでは、[RFC2616]の拡張バッカスナウアフォーム（ABNF）表記を使用し、引用文字列、トークン、SP（スペース）、LOALPHA、DIGITのルールを明示的に含めています。
Additionally, the following rules are included from [RFC3986]: URI and URI-Reference; from [RFC4288]: type-name and subtype-name; from [W3C.REC-html401-19991224]: MediaDesc; from [RFC5646]: Language-Tag; and from [RFC5987], ext-value and parmname.
さらに、[RFC3986]には次のルールが含まれています。URIおよびURI-Reference。 [RFC4288]から：タイプ名とサブタイプ名; [W3C.REC-html401-19991224]から：MediaDesc; [RFC5646]から：言語タグ; [RFC5987]から、ext-valueおよびparmname。
In this specification, a link is a typed connection between two resources that are identified by Internationalised Resource Identifiers (IRIs) [RFC3987], and is comprised of:
この仕様では、リンクは、国際化リソース識別子（IRI）[RFC3987]によって識別される2つのリソース間の型付き接続であり、以下で構成されます。
o A context IRI,
o コンテキストIRI、
o a link relation type (Section 4),
o リンク関係タイプ（セクション4）、
o a target IRI, and
o ターゲットIRI、および
o optionally, target attributes.
o オプションで、ターゲット属性。
A link can be viewed as a statement of the form "{context IRI} has a {relation type} resource at {target IRI}, which has {target attributes}".
リンクは、「{context IRI} has {relation type} resource at {target IRI}、that has {target attributes}」という形式のステートメントとして表示できます。
Note that in the common case, the context IRI will also be a URI [RFC3986], because many protocols (such as HTTP) do not support dereferencing IRIs. Likewise, the target IRI will be converted to a URI (see [RFC3987], Section 3.1) in serialisations that do not support IRIs (e.g., the Link header).
多くのプロトコル（HTTPなど）がIRIの逆参照をサポートしていないため、一般的なケースでは、コンテキストIRIもURI [RFC3986]になることに注意してください。同様に、ターゲットIRIは、IRIをサポートしないシリアル化（リンクヘッダーなど）でURI（[RFC3987]、セクション3.1を参照）に変換されます。
This specification does not place restrictions on the cardinality of links; there can be multiple links to and from a particular IRI, and multiple links of different types between two given IRIs. Likewise, the relative ordering of links in any particular serialisation, or between serialisations (e.g., the Link header and in-content links) is not specified or significant in this specification; applications that wish to consider ordering significant can do so.
この仕様では、リンクのカーディナリティに制限はありません。特定のIRIとの間の複数のリンク、および2つの特定のIRI間の異なるタイプの複数のリンクが存在する可能性があります。同様に、特定のシリアル化、またはシリアル化間のリンクの相対的な順序付け（リンクヘッダーとコンテンツ内リンクなど）は、この仕様では指定されていないか、重要ではありません。重要な順序付けを検討したいアプリケーションは、そうすることができます。
Target attributes are a set of key/value pairs that describe the link or its target; for example, a media type hint. This specification does not attempt to coordinate their names or use, but does provide common target attributes for use in the Link HTTP header.
ターゲット属性は、リンクまたはそのターゲットを説明するキーと値のペアのセットです。たとえば、メディアタイプのヒント。この仕様は、それらの名前の調整や使用を試みませんが、リンクHTTPヘッダーで使用するための共通のターゲット属性を提供します。
Finally, this specification does not define a general syntax for expressing links, nor does it mandate a specific context for any given link; it is expected that serialisations of links will specify both aspects. One such serialisation is communication of links through HTTP headers, specified in Section 5.
最後に、この仕様はリンクを表現するための一般的な構文を定義しておらず、特定のリンクの特定のコンテキストを義務付けていません。リンクのシリアライゼーションは両方の側面を指定することが期待されています。そのようなシリアル化の1つは、セクション5で指定されているHTTPヘッダーを介したリンクの通信です。
In the simplest case, a link relation type identifies the semantics of a link. For example, a link with the relation type "copyright" indicates that the resource identified by the target IRI is a statement of the copyright terms applying to the current context IRI.
最も単純なケースでは、リンク関係タイプはリンクのセマンティクスを識別します。たとえば、関係タイプが「著作権」のリンクは、ターゲットIRIによって識別されるリソースが、現在のコンテキストIRIに適用される著作権用語のステートメントであることを示します。
Link relation types can also be used to indicate that the target resource has particular attributes, or exhibits particular behaviours; for example, a "service" link implies that the identified resource is part of a defined protocol (in this case, a service description).
リンク関係タイプは、ターゲットリソースが特定の属性を持っていること、または特定の動作を示すことを示すためにも使用できます。たとえば、「サービス」リンクは、識別されたリソースが定義されたプロトコル（この場合は、サービスの説明）の一部であることを意味します。
Relation types are not to be confused with media types [RFC4288]; they do not identify the format of the representation that results when the link is dereferenced. Rather, they only describe how the current context is related to another resource.
関係タイプをメディアタイプと混同しないでください[RFC4288]。リンクが逆参照されたときに生じる表現の形式を識別しません。むしろ、現在のコンテキストが別のリソースにどのように関連しているかを説明するだけです。
Relation types SHOULD NOT infer any additional semantics based upon the presence or absence of another link relation type, or its own cardinality of occurrence. An exception to this is the combination of the "alternate" and "stylesheet" registered relation types, which has special meaning in HTML4 for historical reasons.
関係タイプは、別のリンク関係タイプの有無、またはそれ自体の発生のカーディナリティに基づいて、追加のセマンティクスを推測してはなりません（SHOULD NOT）。これの例外は、「代替」と「スタイルシート」の登録済み関係タイプの組み合わせです。これは、歴史的な理由からHTML4で特別な意味を持っています。
There are two kinds of relation types: registered and extension.
関係タイプには、登録済みと拡張の2種類があります。
Well-defined relation types can be registered as tokens for convenience and/or to promote reuse by other applications. This specification establishes an IANA registry of such relation types; see Section 6.2.
明確に定義された関係タイプは、利便性のため、および/または他のアプリケーションによる再利用を促進するために、トークンとして登録できます。この仕様は、そのような関係タイプのIANAレジストリを確立します。セクション6.2を参照してください。
Registered relation type names MUST conform to the reg-rel-type rule, and MUST be compared character-by-character in a case-insensitive fashion. They SHOULD be appropriate to the specificity of the relation type; i.e., if the semantics are highly specific to a particular application, the name should reflect that, so that more general names are available for less specific use.
登録された関係タイプ名は、reg-rel-typeルールに準拠する必要があり、大文字と小文字を区別しない方法で文字ごとに比較する必要があります。それらは、関係タイプの特定性に適切であるべきです。つまり、セマンティクスが特定のアプリケーションに非常に固有である場合、名前はそれを反映している必要があります。これにより、より一般的な名前をあまり具体的でない用途に使用できます。
Registered relation types MUST NOT constrain the media type of the context IRI, and MUST NOT constrain the available representation media types of the target IRI. However, they can specify the behaviours and properties of the target resource (e.g., allowable HTTP methods, request and response media types that must be supported).
登録された関係タイプは、コンテキストIRIのメディアタイプを制約してはならず（MUST NOT）、ターゲットIRIの利用可能な表現メディアタイプを制約してはなりません（MUST NOT）。ただし、ターゲットリソースの動作とプロパティ（たとえば、サポートされる必要のある許可されたHTTPメソッド、要求と応答のメディアタイプ）を指定できます。
Additionally, specific applications of linking may require additional data to be included in the registry. For example, Web browsers might want to know what kinds of links should be downloaded when they archive a Web page; if this application-specific information is in the registry, new link relation types can control this behaviour without unnecessary coordination.
さらに、リンクの特定のアプリケーションでは、レジストリに追加のデータを含める必要がある場合があります。たとえば、Webブラウザは、Webページをアーカイブするときにダウンロードする必要があるリンクの種類を知りたい場合があります。このアプリケーション固有の情報がレジストリにある場合、新しいリンク関係タイプは、不要な調整なしでこの動作を制御できます。
To accommodate this, per-entry application data can be added to the Link Relation Type registry, by registering it in the Link Relation Application Data registry (Section 6.3).
これに対応するために、エントリごとのアプリケーションデータをリンク関係アプリケーションデータレジストリに登録することにより、リンク関係タイプレジストリに追加できます（セクション6.3）。
Applications that don't wish to register a relation type can use an extension relation type, which is a URI [RFC3986] that uniquely identifies the relation type. Although the URI can point to a resource that contains a definition of the semantics of the relation type, clients SHOULD NOT automatically access that resource to avoid overburdening its server.
関係タイプを登録したくないアプリケーションは、関係タイプを一意に識別するURI [RFC3986]である拡張関係タイプを使用できます。 URIは、関係タイプのセマンティクスの定義を含むリソースを指すことができますが、サーバーの過負荷を避けるために、クライアントはそのリソースに自動的にアクセスしてはなりません（SHOULD NOT）。
When extension relation types are compared, they MUST be compared as strings (after converting to URIs if serialised in a different format, such as a Curie [W3C.CR-curie-20090116]) in a case-insensitive fashion, character-by-character. Because of this, all-lowercase URIs SHOULD be used for extension relations.
拡張リレーションタイプを比較する場合、それらは文字列として比較する必要があります（キュリー[W3C.CR-curie-20090116]などの別の形式でシリアル化されている場合はURIに変換した後）。キャラクター。このため、すべて小文字のURIを拡張関係に使用する必要があります（SHOULD）。
Note that while extension relation types are required to be URIs, a serialisation of links can specify that they are expressed in another form, as long as they can be converted to URIs.
拡張リレーションタイプはURIである必要がありますが、リンクのシリアル化では、URIに変換できる限り、リンクを別の形式で表現するように指定できます。
The Link entity-header field provides a means for serialising one or more links in HTTP headers. It is semantically equivalent to the <LINK> element in HTML, as well as the atom:link feed-level element in Atom [RFC4287].
Linkエンティティヘッダーフィールドは、HTTPヘッダー内の1つ以上のリンクをシリアル化する手段を提供します。これは、HTMLの<LINK>要素、およびAtom [RFC4287]のatom：linkフィードレベル要素と意味的に同等です。
Link = "Link" ":" #link-value
link-value = "<" URI-Reference ">" *( ";" link-param )
link-param = ( ( "rel" "=" relation-types )
| ( "anchor" "=" <"> URI-Reference <"> )
| ( "rev" "=" relation-types )
| ( "hreflang" "=" Language-Tag )
| ( "media" "=" ( MediaDesc | ( <"> MediaDesc <"> ) ) )
| ( "title" "=" quoted-string )
| ( "title*" "=" ext-value )
| ( "type" "=" ( media-type | quoted-mt ) )
| ( link-extension ) )
link-extension = ( parmname [ "=" ( ptoken | quoted-string ) ] )
| ( ext-name-star "=" ext-value )
ext-name-star = parmname "*" ; reserved for RFC2231-profiled
; extensions. Whitespace NOT
; allowed in between.
ptoken = 1*ptokenchar
ptokenchar = "!" | "#" | "$" | "%" | "&" | "'" | "("
| ")" | "*" | "+" | "-" | "." | "/" | DIGIT
| ":" | "<" | "=" | ">" | "?" | "@" | ALPHA
| "[" | "]" | "^" | "_" | "`" | "{" | "|"
| "}" | "~"
media-type = type-name "/" subtype-name
quoted-mt = <"> media-type <">
relation-types = relation-type
| <"> relation-type *( 1*SP relation-type ) <">
relation-type = reg-rel-type | ext-rel-type
reg-rel-type = LOALPHA *( LOALPHA | DIGIT | "." | "-" )
ext-rel-type = URI
Each link-value conveys one target IRI as a URI-Reference (after conversion to one, if necessary; see [RFC3987], Section 3.1) inside angle brackets ("<>"). If the URI-Reference is relative, parsers MUST resolve it as per [RFC3986], Section 5. Note that any base IRI from the message's content is not applied.
各リンク値は、1つのターゲットIRIをURI参照として伝えます（必要に応じて1に変換した後。[RFC3987]、セクション3.1を参照）山かっこ（ "<>"）内。 URI参照が相対である場合、パーサーは[RFC3986]のセクション5に従って解決する必要があります。メッセージのコンテンツからのベースIRIは適用されないことに注意してください。
By default, the context of a link conveyed in the Link header field is the IRI of the requested resource.
デフォルトでは、リンクヘッダーフィールドで伝達されるリンクのコンテキストは、要求されたリソースのIRIです。
When present, the anchor parameter overrides this with another URI, such as a fragment of this resource, or a third resource (i.e., when the anchor value is an absolute URI). If the anchor parameter's value is a relative URI, parsers MUST resolve it as per [RFC3986], Section 5. Note that any base URI from the body's content is not applied.
アンカーパラメータが存在する場合は、このリソースのフラグメントや3番目のリソースなどの別のURIでこれをオーバーライドします（つまり、アンカー値が絶対URIの場合）。アンカーパラメータの値が相対URIの場合、パーサーは[RFC3986]のセクション5に従って解決する必要があります。本文のコンテンツからのベースURIは適用されないことに注意してください。
Consuming implementations can choose to ignore links with an anchor parameter. For example, the application in use may not allow the context IRI to be assigned to a different resource. In such cases, the entire link is to be ignored; consuming implementations MUST NOT process the link without applying the anchor.
使用する実装では、アンカーパラメータを持つリンクを無視することを選択できます。たとえば、使用中のアプリケーションでは、コンテキストIRIを別のリソースに割り当てることができない場合があります。そのような場合、リンク全体が無視されます。消費する実装は、アンカーを適用せずにリンクを処理してはなりません（MUST NOT）。
Note that depending on HTTP status code and response headers, the context IRI might be "anonymous" (i.e., no context IRI is available). For instance, this is the case on a 404 response to a GET request.
HTTPステータスコードと応答ヘッダーによっては、コンテキストIRIが「匿名」である可能性があることに注意してください（つまり、コンテキストIRIは使用できません）。たとえば、GETリクエストに対する404レスポンスの場合がこれに該当します。
The relation type of a link is conveyed in the "rel" parameter's value. The "rel" parameter MUST NOT appear more than once in a given link-value; occurrences after the first MUST be ignored by parsers.
リンクの関係タイプは、「rel」パラメーターの値で伝達されます。 「rel」パラメータは、特定のリンク値に複数回出現してはなりません（MUST NOT）。最初の後ろの出現はパーサーによって無視されなければなりません。
The "rev" parameter has been used in the past to indicate that the semantics of the relationship are in the reverse direction. That is, a link from A to B with REL="X" expresses the same relationship as a link from B to A with REV="X". "rev" is deprecated by this specification because it often confuses authors and readers; in most cases, using a separate relation type is preferable.
「rev」パラメータは、関係のセマンティクスが逆方向であることを示すために過去に使用されていました。つまり、REL = "X"のAからBへのリンクは、REV = "X"のBからAへのリンクと同じ関係を表します。 「rev」は、作者と読者を混乱させることが多いため、この仕様では推奨されません。ほとんどの場合、別の関係タイプを使用することをお勧めします。
Note that extension relation types are REQUIRED to be absolute URIs in Link headers, and MUST be quoted if they contain a semicolon (";") or comma (",") (as these characters are used as delimiters in the header itself).
拡張リレーションタイプは、リンクヘッダーの絶対URIである必要があり、セミコロン（ ";"）またはコンマ（ "、"）が含まれている場合は引用符で囲む必要があります（これらの文字はヘッダー自体の区切り文字として使用されるため）。
The "hreflang", "media", "title", "title*", "type", and any link-extension link-params are considered to be target attributes for the link.
「hreflang」、「media」、「title」、「title *」、「type」、および任意のlink-extension link-paramsは、リンクのターゲット属性と見なされます。
The "hreflang" parameter, when present, is a hint indicating what the language of the result of dereferencing the link should be. Note that this is only a hint; for example, it does not override the Content-Language header of a HTTP response obtained by actually following the link. Multiple "hreflang" parameters on a single link-value indicate that multiple languages are available from the indicated resource.
「hreflang」パラメータは、存在する場合、リンクを逆参照した結果の言語が何であるかを示すヒントです。これは単なるヒントであることに注意してください。たとえば、実際にリンクをたどって取得したHTTP応答のContent-Languageヘッダーは上書きされません。単一のリンク値に複数の「hreflang」パラメーターがある場合は、指定されたリソースから複数の言語を利用できることを示しています。
The "media" parameter, when present, is used to indicate intended destination medium or media for style information (see [W3C.REC-html401-19991224], Section 6.13). Note that this may be updated by [W3C.CR-css3-mediaqueries-20090915]). Its value MUST be quoted if it contains a semicolon (";") or comma (","), and there MUST NOT be more than one "media" parameter in a link-value.
「media」パラメータは、存在する場合、スタイル情報の目的の宛先メディアを示すために使用されます（[W3C.REC-html401-19991224]、セクション6.13を参照）。これは[W3C.CR-css3-mediaqueries-20090915]）によって更新される可能性があることに注意してください。セミコロン（ ";"）またはコンマ（ "、"）が含まれている場合は、その値を引用符で囲む必要があり、リンク値に複数の「メディア」パラメーターがあってはなりません。
The "title" parameter, when present, is used to label the destination of a link such that it can be used as a human-readable identifier (e.g., a menu entry) in the language indicated by the Content-Language header (if present). The "title" parameter MUST NOT appear more than once in a given link-value; occurrences after the first MUST be ignored by parsers.
「title」パラメータは、存在する場合、Content-Languageヘッダー（存在する場合）によって示される言語で人間が読み取れる識別子（たとえば、メニューエントリ）として使用できるように、リンクの宛先にラベルを付けるために使用されます。 ）。 「title」パラメータは、特定のリンク値で複数回使用してはなりません。最初の後ろの出現はパーサーによって無視されなければなりません。
The "title*" parameter can be used to encode this label in a different character set, and/or contain language information as per [RFC5987]. The "title*" parameter MUST NOT appear more than once in a given link-value; occurrences after the first MUST be ignored by parsers. If the parameter does not contain language information, its language is indicated by the Content-Language header (when present).
「title *」パラメータを使用して、このラベルを別の文字セットでエンコードしたり、[RFC5987]のように言語情報を含めたりできます。 "title *"パラメータは、特定のリンク値に複数回出現してはなりません（MUST NOT）。最初の後ろの出現はパーサーによって無視されなければなりません。パラメータに言語情報が含まれていない場合、その言語はContent-Languageヘッダー（存在する場合）で示されます。
If both the "title" and "title*" parameters appear in a link-value, processors SHOULD use the "title*" parameter's value.
「title」パラメータと「title *」パラメータの両方がリンク値に含まれている場合、プロセッサは「title *」パラメータの値を使用する必要があります（SHOULD）。
The "type" parameter, when present, is a hint indicating what the media type of the result of dereferencing the link should be. Note that this is only a hint; for example, it does not override the Content-Type header of a HTTP response obtained by actually following the link. There MUST NOT be more than one type parameter in a link-value.
「type」パラメータは、存在する場合、リンクを逆参照した結果のメディアタイプを示すヒントです。これは単なるヒントであることに注意してください。たとえば、実際にリンクをたどって取得したHTTP応答のContent-Typeヘッダーはオーバーライドされません。リンク値に複数のタイプパラメータがあってはなりません。
For example:
例えば：
Link: <http://example.com/TheBook/chapter2>; rel="previous";
title="previous chapter"
indicates that "chapter2" is previous to this resource in a logical navigation path.
「chapter2」が論理ナビゲーションパスでこのリソースの前にあることを示します。
Similarly,
同様に、
Link: </>; rel="http://example.net/foo"
indicates that the root resource ("/") is related to this resource with the extension relation type "http://example.net/foo".
ルートリソース（ "/"）が、このリソースに拡張関係タイプ "http://example.net/foo"で関連付けられていることを示します。
The example below shows an instance of the Link header encoding multiple links, and also the use of RFC 2231 encoding to encode both non-ASCII characters and language information.
以下の例は、複数のリンクをエンコードするリンクヘッダーのインスタンスと、非ASCII文字と言語情報の両方をエンコードするためのRFC 2231エンコードの使用を示しています。
Link: </TheBook/chapter2>;
rel="previous"; title*=UTF-8'de'letztes%20Kapitel,
</TheBook/chapter4>;
rel="next"; title*=UTF-8'de'n%c3%a4chstes%20Kapitel
Here, both links have titles encoded in UTF-8, use the German language ("de"), and the second link contains the Unicode code point U+00E4 ("LATIN SMALL LETTER A WITH DIAERESIS").
ここで、両方のリンクのタイトルはUTF-8でエンコードされ、ドイツ語（ "de"）を使用し、2番目のリンクにはUnicodeコードポイントU + 00E4（ "ラテン小文字Aダイアレシス"）が含まれています。
Note that link-values can convey multiple links between the same target and context IRIs; for example:
リンク値は、同じターゲットとコンテキストIRIの間の複数のリンクを伝達できることに注意してください。例えば：
Link: <http://example.org/>;
rel="start http://example.net/relation/other"
Here, the link to "http://example.org/" has the registered relation type "start" and the extension relation type "http://example.net/relation/other".
ここで、「http://example.org/」へのリンクには、関係タイプ「start」と拡張関係タイプ「http://example.net/relation/other」が登録されています。
This specification updates the Message Header registry entry for "Link" in HTTP [RFC3864] to refer to this document.
この仕様は、このドキュメントを参照するために、HTTP [RFC3864]の「リンク」のメッセージヘッダーレジストリエントリを更新します。
Header field: Link Applicable protocol: http Status: standard Author/change controller: IETF (iesg@ietf.org) Internet Engineering Task Force Specification document(s): [RFC5988]
ヘッダーフィールド：リンク該当するプロトコル：httpステータス：標準の作成者/変更コントローラー：IETF（iesg@ietf.org）インターネット技術特別調査委員会の仕様書：[RFC5988]
This specification establishes the Link Relation Type registry, and updates Atom [RFC4287] to refer to it in place of the "Registry of Link Relations".
この仕様は、リンク関係タイプレジストリを確立し、「リンク関係のレジストリ」の代わりにそれを参照するようにAtom [RFC4287]を更新します。
The underlying registry data (e.g., the XML file) must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions (<http://trustee.ietf.org/license-info>).
基になるレジストリデータ（XMLファイルなど）には、Trust Legal Provisions（<http://trustee.ietf.org/license-info>）のセクション4.eで説明されているように、簡易BSDライセンステキストを含める必要があります。
Relation types are registered on the advice of a Designated Expert (appointed by the IESG or their delegate), with a Specification Required (using terminology from [RFC5226]).
関係タイプは、指定された専門家（IESGまたはその代理人によって任命）のアドバイスに基づいて、（[RFC5226]の用語を使用して）必要な仕様とともに登録されます。
The requirements for registered relation types are described in Section 4.1.
登録された関係タイプの要件については、セクション4.1で説明します。
Registration requests consist of the completed registration template below, typically published in an RFC or Open Standard (in the sense described by [RFC2026], Section 7). However, 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.
登録リクエストは、以下の完成した登録テンプレートで構成され、通常はRFCまたはオープンスタンダードで公開されます（[RFC2026]、セクション7で説明されている意味で）。ただし、公開前の値の割り当てを可能にするために、指定された専門家は、仕様が公開されることに納得したら、登録を承認することができます。
Note that relation types can be registered by third parties, if the Designated Expert determines that an unregistered relation type is widely deployed and not likely to be registered in a timely manner.
指定専門家が未登録の関係タイプが広く展開されており、適時に登録される可能性が低いと判断した場合、関係タイプをサードパーティが登録できることに注意してください。
The registration template is:
登録テンプレートは次のとおりです。
o Relation Name:
o リレーション名：
o Description:
o 説明：
o Reference:
o 参照：
o Notes: [optional]
o 注：[オプション]
o Application Data: [optional]
o アプリケーションデータ：[オプション]
Registration requests should be sent to the link-relations@ietf.org mailing list, marked clearly in the subject line (e.g., "NEW RELATION - example" to register an "example" relation type).
登録リクエストは、件名に明確にマークされたlink-relations@ietf.orgメーリングリストに送信する必要があります（たとえば、「例」の関係タイプを登録するには、「NEW RELATION-example」）。
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 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@iesg.org mailing list).
Designated Expertによる決定（またはその欠如）は、最初にApplication Area Directors（app-ads@tools.ietf.orgメールアドレスを使用して連絡可能、またはhttp：//www.iesgでメールアドレスを直接検索して連絡できます）にアピールできます。 org /ウェブサイト）、上訴人が回答に満足していない場合は、IESG全体（iesg@iesg.orgメーリングリストを使用）へ。
IANA should only accept registry updates from the Designated Expert(s), and should direct all requests for registration to the review mailing list.
IANAは、指定された専門家からのレジストリの更新のみを受け入れ、登録のすべてのリクエストをレビューメーリングリストに転送する必要があります。
The Link Relation Type registry's initial contents are:
Link Relation Typeレジストリの初期コンテンツは次のとおりです。
o Relation Name: alternate o Description: Designates a substitute for the link's context. o Reference: [W3C.REC-html401-19991224]
o リレーション名：代替o説明：リンクのコンテキストの代替を指定します。 o参照：[W3C.REC-html401-19991224]
o Relation Name: appendix o Description: Refers to an appendix. o Reference: [W3C.REC-html401-19991224]
o リレーション名：付録o説明：付録を参照します。 o参照：[W3C.REC-html401-19991224]
o Relation Name: bookmark o Description: Refers to a bookmark or entry point. o Reference: [W3C.REC-html401-19991224]
o リレーション名：ブックマークo説明：ブックマークまたはエントリポイントを参照します。 o参照：[W3C.REC-html401-19991224]
o Relation Name: chapter o Description: Refers to a chapter in a collection of resources. o Reference: [W3C.REC-html401-19991224]
o リレーション名：章o説明：リソースのコレクションの章を参照します。 o参照：[W3C.REC-html401-19991224]
o Relation Name: contents o Description: Refers to a table of contents. o Reference: [W3C.REC-html401-19991224]
o リレーション名：内容o説明：目次を参照します。 o参照：[W3C.REC-html401-19991224]
o Relation Name: copyright o Description: Refers to a copyright statement that applies to the link's context. o Reference: [W3C.REC-html401-19991224]
o リレーション名：copyright o説明：リンクのコンテキストに適用される著作権ステートメントを指します。 o参照：[W3C.REC-html401-19991224]
o Relation Name: current o Description: Refers to a resource containing the most recent item(s) in a collection of resources. o Reference: [RFC5005]
o リレーション名：current o説明：リソースのコレクション内の最新のアイテムを含むリソースを参照します。 o参照：[RFC5005]
o Relation Name: describedby o Description: Refers to a resource providing information about the link's context. o Documentation: <http://www.w3.org/TR/powder-dr/#assoc-linking>
o リレーション名：describeby o説明：リンクのコンテキストに関する情報を提供するリソースを参照します。 oドキュメント：<http://www.w3.org/TR/powder-dr/#assoc-linking>
o Relation Name: edit
o Description: Refers to a resource that can be used to edit the
link's context.
o Reference: [RFC5023]
o Relation Name: edit-media
o Description: Refers to a resource that can be used to edit media
associated with the link's context.
o Reference: [RFC5023]
o Relation Name: enclosure o Description: Identifies a related resource that is potentially large and might require special handling. o Reference: [RFC4287]
o 関係名：エンクロージャo説明：潜在的に大きく、特別な処理が必要になる可能性がある関連リソースを識別します。 o参照：[RFC4287]
o Relation Name: first o Description: An IRI that refers to the furthest preceding resource in a series of resources. o Reference: [RFC5988] o Notes: this relation type registration did not indicate a reference. Originally requested by Mark Nottingham in December 2004.
o リレーション名：最初o説明：一連のリソースの中で最も遠い先行リソースを参照するIRI。 o参照：[RFC5988] o注：この関係タイプの登録は参照を示していませんでした。もともとは2004年12月にマーク・ノッティンガムによって要求されました。
o Relation Name: glossary o Description: Refers to a glossary of terms. o Reference: [W3C.REC-html401-19991224]
o リレーション名：用語集o説明：用語集を参照します。 o参照：[W3C.REC-html401-19991224]
o Relation Name: help o Description: Refers to a resource offering help (more information, links to other sources information, etc.) o Reference: [W3C.REC-html401-19991224]
o リレーション名：ヘルプo説明：リソース提供ヘルプを参照します（詳細、他のソース情報へのリンクなど）oリファレンス：[W3C.REC-html401-19991224]
o Relation Name: hub o Description: Refers to a hub that enables registration for notification of updates to the context. o Reference: <http://pubsubhubbub.googlecode.com/> <http:// pubsubhubbub.googlecode.com/svn/trunk/pubsubhubbub-core-0.3.html> o Notes: this relation type was requested by Brett Slatkin.
o リレーション名：ハブo説明：コンテキストへの更新の通知の登録を可能にするハブを指します。 o参照：<http://pubsubhubbub.googlecode.com/> <http：// pubsubhubbub.googlecode.com/svn/trunk/pubsubhubbub-core-0.3.html>注：この関係タイプは、Brett Slatkinによって要求されました。
o Relation Name: index o Description: Refers to an index. o Reference: [W3C.REC-html401-19991224]
o リレーション名：インデックスo説明：インデックスを参照します。 o参照：[W3C.REC-html401-19991224]
o Relation Name: last o Description: An IRI that refers to the furthest following resource in a series of resources. o Reference: [RFC5988] o Notes: this relation type registration did not indicate a reference. Originally requested by Mark Nottingham in December 2004.
o リレーション名：最後のo説明：一連のリソースの中で最も遠い後続のリソースを参照するIRI。 o参照：[RFC5988] o注：この関係タイプの登録は参照を示していませんでした。もともとは2004年12月にマーク・ノッティンガムによって要求されました。
o Relation Name: latest-version o Description: Points to a resource containing the latest (e.g., current) version of the context. o Reference: [RFC5829]
o リレーション名：latest-version o説明：コンテキストの最新（たとえば、現在）バージョンを含むリソースを指します。 o参照：[RFC5829]
o Relation Name: license o Description: Refers to a license associated with the link's context. o Reference: [RFC4946]
o リレーション名：ライセンスo説明：リンクのコンテキストに関連付けられたライセンスを参照します。 o参照：[RFC4946]
o Relation Name: next o Description: Refers to the next resource in a ordered series of resources. o Reference: [W3C.REC-html401-19991224]
o リレーション名：次o説明：順序付けられた一連のリソースの次のリソースを参照します。 o参照：[W3C.REC-html401-19991224]
o Relation Name: next-archive o Description: Refers to the immediately following archive resource. o Reference: [RFC5005]
o リレーション名：next-archive o説明：直後のアーカイブリソースを参照します。 o参照：[RFC5005]
o Relation Name: payment o Description: indicates a resource where payment is accepted. o Reference: [RFC5988] o Notes: this relation type registration did not indicate a reference. Requested by Joshua Kinberg and Robert Sayre. It is meant as a general way to facilitate acts of payment, and thus this specification makes no assumptions on the type of payment or transaction protocol. Examples may include a Web page where donations are accepted or where goods and services are available for purchase. rel="payment" is not intended to initiate an automated transaction. In Atom documents, a link element with a rel="payment" attribute may exist at the feed/channel level and/or the entry/item level. For example, a rel="payment" link at the feed/channel level may point to a "tip jar" URI, whereas an entry/ item containing a book review may include a rel="payment" link that points to the location where the book may be purchased through an online retailer.
o リレーション名：支払いo説明：支払いが受け入れられるリソースを示します。 o参照：[RFC5988] o注：この関係タイプの登録は参照を示していませんでした。ジョシュア・キンバーグとロバート・セイヤーからの要請。これは、支払い行為を容易にする一般的な方法として意図されているため、この仕様では、支払いのタイプやトランザクションプロトコルについては想定していません。例としては、寄付を受け入れるか、商品やサービスを購入できるWebページが含まれます。 rel = "payment"は、自動化されたトランザクションを開始するためのものではありません。 Atomドキュメントでは、rel = "payment"属性を持つlink要素は、フィード/チャネルレベルおよび/またはエントリ/アイテムレベルで存在する場合があります。たとえば、フィード/チャネルレベルのrel = "payment"リンクは「tip jar」URIを指す場合がありますが、書評を含むエントリ/アイテムには、次の場所を指すrel = "payment"リンクを含めることができます。この本はオンライン小売業者から購入できます。
o Relation Name: prev o Description: Refers to the previous resource in an ordered series of resources. Synonym for "previous". o Reference: [W3C.REC-html401-19991224]
o リレーション名：prev o説明：順序付けられた一連のリソースの前のリソースを参照します。 「previous」の同義語。 o参照：[W3C.REC-html401-19991224]
o Relation Name: predecessor-version
o Description: Points to a resource containing the predecessor
version in the version history.
o Reference: [RFC5829]
o Relation Name: previous
o Description: Refers to the previous resource in an ordered series
of resources. Synonym for "prev".
o Reference: [W3C.REC-html401-19991224]
o Relation Name: prev-archive o Description: Refers to the immediately preceding archive resource. o Reference: [RFC5005]
o リレーション名：prev-archive o説明：直前のアーカイブリソースを参照します。 o参照：[RFC5005]
o Relation Name: related o Description: Identifies a related resource. o Reference: [RFC4287]
o 関係名：関連o説明：関連リソースを識別します。 o参照：[RFC4287]
o Relation Name: replies o Description: Identifies a resource that is a reply to the context of the link. o Reference: [RFC4685]
o リレーション名：返信o説明：リンクのコンテキストへの返信であるリソースを識別します。 o参照：[RFC4685]
o Relation Name: section o Description: Refers to a section in a collection of resources. o Reference: [W3C.REC-html401-19991224]
o リレーション名：セクションo説明：リソースのコレクションのセクションを参照します。 o参照：[W3C.REC-html401-19991224]
o Relation Name: self o Description: Conveys an identifier for the link's context. o Reference: [RFC4287]
o リレーション名：self o説明：リンクのコンテキストの識別子を伝えます。 o参照：[RFC4287]
o Relation Name: service o Description: Indicates a URI that can be used to retrieve a service document. o Reference: [RFC5023] o Notes: When used in an Atom document, this relation type specifies Atom Publishing Protocol service documents by default. Requested by James Snell.
o リレーション名：service o説明：サービスドキュメントを取得するために使用できるURIを示します。 o参照：[RFC5023] o注：Atomドキュメントで使用される場合、このリレーションタイプはデフォルトでAtom Publishing Protocolサービスドキュメントを指定します。 James Snellからのリクエスト。
o Relation Name: start o Description: Refers to the first resource in a collection of resources. o Reference: [W3C.REC-html401-19991224]
o リレーション名：start o説明：リソースのコレクションの最初のリソースを参照します。 o参照：[W3C.REC-html401-19991224]
o Relation Name: stylesheet o Description: Refers to an external style sheet. o Reference: [W3C.REC-html401-19991224]
o リレーション名：スタイルシートo説明：外部スタイルシートを参照します。 o参照：[W3C.REC-html401-19991224]
o Relation Name: subsection o Description: Refers to a resource serving as a subsection in a collection of resources. o Reference: [W3C.REC-html401-19991224]
o リレーション名：サブセクションo説明：リソースのコレクションのサブセクションとして機能するリソースを参照します。 o参照：[W3C.REC-html401-19991224]
o Relation Name: successor-version o Description: Points to a resource containing the successor version in the version history. o Reference: [RFC5829]
o リレーション名：successor-version o説明：バージョン履歴の後続バージョンを含むリソースを指します。 o参照：[RFC5829]
o Relation Name: up o Description: Refers to a parent document in a hierarchy of documents. o Reference: [RFC5988] o Notes: this relation type registration did not indicate a reference. Requested by Noah Slater.
o リレーション名：up o説明：ドキュメントの階層内の親ドキュメントを参照します。 o参照：[RFC5988] o注：この関係タイプの登録は参照を示していませんでした。 Noah Slaterからのリクエスト。
o Relation Name: version-history o Description: points to a resource containing the version history for the context. o Reference: [RFC5829]
o リレーション名：version-history o説明：コンテキストのバージョン履歴を含むリソースを指します。 o参照：[RFC5829]
o Relation Name: via o Description: Identifies a resource that is the source of the information in the link's context. o Reference: [RFC4287]
o リレーション名：via o説明：リンクのコンテキスト内の情報のソースであるリソースを識別します。 o参照：[RFC4287]
o Relation Name: working-copy o Description: Points to a working copy for this resource. o Reference: [RFC5829]
o リレーション名：説明の作業コピー：このリソースの作業コピーを指します。または参照：[RFC5829]
o Relation Name: working-copy-of o Description: Points to the versioned resource from which this working copy was obtained. o Reference: [RFC5829]
o リレーション名：working-copy-of o説明：この作業コピーの取得元のバージョン付きリソースを指します。 o参照：[RFC5829]
This specification also establishes the Link Relation Application Field registry, to allow entries in the Link Relation Type registry to be extended with application-specific data (hereafter, "app data") specific to all instances of a given link relation type.
この仕様はまた、リンク関係アプリケーションフィールドレジストリを確立し、リンク関係タイプレジストリのエントリを、特定のリンク関係タイプのすべてのインスタンスに固有のアプリケーション固有のデータ（以下、「アプリデータ」）で拡張できるようにします。
Application data is registered on the advice of a Designated Expert (appointed by the IESG or their delegate), with a Specification Required (using terminology from [RFC5226]).
アプリケーションデータは、指定された専門家（IESGまたはその代理人によって任命）のアドバイスに基づいて、必要な仕様（[RFC5226]の用語を使用）とともに登録されます。
Registration requests consist of the completed registration template below:
登録リクエストは、以下の完成した登録テンプレートで構成されています。
o Application Name:
o アプリケーション名：
o Description:
o 説明：
o Default Value:
o デフォルト値：
o Notes: [optional]
o 注：[オプション]
The Description SHOULD identify the value space of the app data. The Default Value MUST be appropriate to entries to which the app data does not apply.
説明は、アプリデータの値スペースを識別する必要があります。デフォルト値は、アプリデータが適用されないエントリに適切である必要があります。
Entries that pre-date the addition of app data will automatically be considered to have the default value for that app data; if there are exceptions, the modification of such entries should be coordinated by the Designated Expert(s), in consultation with the author of the proposed app data as well as the registrant of the existing entry (if possible).
アプリデータの追加より前のエントリは、そのアプリデータのデフォルト値を持つと自動的に見なされます。例外がある場合、そのようなエントリの変更は、提案されたアプリデータの作成者および既存のエントリの登録者（可能な場合）と相談して、指定された専門家が調整する必要があります。
Registration requests should be sent to the link-relations@ietf.org mailing list, marked clearly in the subject line (e.g., "NEW APP DATA - example" to register "example" app data).
登録リクエストは、件名に明確にマークされたlink-relations@ietf.orgメーリングリストに送信する必要があります（「例」アプリデータを登録するには、「NEW APP DATA-example」など）。
Within at most 14 days of the request, the Designated Expert will either approve or deny the registration request, communicating this decision to the review list. Denials should include an explanation and, if applicable, suggestions as to how to make the request successful. Registration requests that are undetermined for a period longer than 21 days can be brought to the IESG's attention (using the iesg@iesg.org mailing list) for resolution.
指定されたエキスパートは、リクエストから最大14日以内に登録リクエストを承認または拒否し、この決定をレビューリストに伝えます。拒否には、要求を成功させる方法についての説明と、該当する場合は提案を含める必要があります。 21日よりも長い期間未定の登録要求は、解決のために（iesg@iesg.orgメーリングリストを使用して）IESGの注意を引くことができます。
When a registration request is successful, the Designated Expert will forward it to IANA for publication. IANA should only accept registry updates from the Designated Expert(s), and should direct all requests for registration to the review mailing list.
登録リクエストが成功すると、Designated ExpertはそれをIANAに転送して公開します。 IANAは、指定された専門家からのレジストリの更新のみを受け入れ、登録のすべてのリクエストをレビューメーリングリストに転送する必要があります。
The content of the Link header field is not secure, private or integrity-guaranteed, and due caution should be exercised when using it. Use of Transport Layer Security (TLS) with HTTP ([RFC2818] and [RFC2817]) is currently the only end-to-end way to provide such protection.
Linkヘッダーフィールドの内容は、安全、プライベート、または整合性が保証されていないため、使用する際には十分な注意が必要です。 HTTP（[RFC2818]および[RFC2817]）でのトランスポート層セキュリティ（TLS）の使用は、現在、このような保護を提供する唯一のエンドツーエンドの方法です。
Applications that take advantage of typed links should consider the attack vectors opened by automatically following, trusting, or otherwise using links gathered from HTTP headers. In particular, Link headers that use the "anchor" parameter to associate a link's context with another resource should be treated with due caution.
型付きリンクを利用するアプリケーションは、HTTPヘッダーから収集されたリンクを自動的に追跡、信頼、またはその他の方法で使用することにより開かれた攻撃ベクトルを考慮する必要があります。特に、「アンカー」パラメーターを使用してリンクのコンテキストを別のリソースに関連付けるリンクヘッダーは、十分に注意して扱う必要があります。
The Link entity-header field makes extensive use of IRIs and URIs. See [RFC3987] for security considerations relating to IRIs. See [RFC3986] for security considerations relating to URIs. See [RFC2616] for security considerations relating to HTTP headers.
Linkエンティティヘッダーフィールドは、IRIとURIを広範囲に使用します。 IRIに関連するセキュリティの考慮事項については、[RFC3987]を参照してください。 URIに関連するセキュリティの考慮事項については、[RFC3986]を参照してください。 HTTPヘッダーに関連するセキュリティの考慮事項については、[RFC2616]を参照してください。
Target IRIs may need to be converted to URIs in order to express them in serialisations that do not support IRIs. This includes the Link HTTP header.
ターゲットIRIは、IRIをサポートしないシリアル化でそれらを表現するために、URIに変換する必要がある場合があります。これには、Link HTTPヘッダーが含まれます。
Similarly, the anchor parameter of the Link header does not support IRIs, and therefore IRIs must be converted to URIs before inclusion there.
同様に、LinkヘッダーのアンカーパラメーターはIRIをサポートしていないため、IRIをそこに含める前にURIに変換する必要があります。
Relation types are defined as URIs, not IRIs, to aid in their comparison. It is not expected that they will be displayed to end users.
関係タイプは、比較を支援するために、IRIではなくURIとして定義されます。それらがエンドユーザーに表示されることは想定されていません。
[RFC2026] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996.
[RFC2026] Bradner、S。、「インターネット標準プロセス-リビジョン3」、BCP 9、RFC 2026、1996年10月。
[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、「Hypertext Transfer Protocol-HTTP / 1.1」 、RFC 2616、1999年6月。
[RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration Procedures for Message Header Fields", BCP 90, RFC 3864, September 2004.
[RFC3864]クライン、G。、ノッティンガム、M。、およびJ.モーグル、「メッセージヘッダーフィールドの登録手順」、BCP 90、RFC 3864、2004年9月。
[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月。
[RFC3987] Duerst, M. and M. Suignard, "Internationalized Resource Identifiers (IRIs)", RFC 3987, January 2005.
[RFC3987] Duerst、M。およびM. Suignard、「Internationalized Resource Identifiers（IRIs）」、RFC 3987、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月。
[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月。
[RFC2068] Fielding, R., Gettys, J., Mogul, J., Nielsen, H., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2068, January 1997.
[RFC2068] Fielding、R.、Gettys、J.、Mogul、J.、Nielsen、H。、およびT. Berners-Lee、「Hypertext Transfer Protocol-HTTP / 1.1」、RFC 2068、1997年1月。
[RFC2817] Khare, R. and S. Lawrence, "Upgrading to TLS Within HTTP/1.1", RFC 2817, May 2000.
[RFC2817] Khare、R。およびS. Lawrence、「Upgrading to TLS within HTTP / 1.1」、RFC 2817、2000年5月。
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
[RFC2818] Rescorla、E。、「HTTP over TLS」、RFC 2818、2000年5月。
[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月。
[RFC4685] Snell, J., "Atom Threading Extensions", RFC 4685, September 2006.
[RFC4685] Snell、J。、「Atom Threading Extensions」、RFC 4685、2006年9月。
[RFC4946] Snell, J., "Atom License Extension", RFC 4946, July 2007.
[RFC4946] Snell、J。、「Atom License Extension」、RFC 4946、2007年7月。
[RFC5005] Nottingham, M., "Feed Paging and Archiving", RFC 5005, September 2007.
[RFC5005]ノッティンガム、M。、「フィードのページングとアーカイブ」、RFC 5005、2007年9月。
[RFC5023] Gregorio, J. and B. de hOra, "The Atom Publishing Protocol", RFC 5023, October 2007.
[RFC5023] Gregorio、J。およびB. de hOra、「The Atom Publishing Protocol」、RFC 5023、2007年10月。
[RFC5829] Brown, A., Clemm, G., and J. Reschke, "Link Relation Types for Simple Version Navigation between Web Resources", RFC 5829, April 2010.
[RFC5829] Brown、A.、Clemm、G。、およびJ. Reschke、「Webリソース間の単純なバージョンナビゲーションのためのリンク関係タイプ」、RFC 5829、2010年4月。
[W3C.CR-css3-mediaqueries-20090915] van Kesteren, A., Glazman, D., Lie, H., and T. Celik, "Media Queries", W3C Candidate Recommendation CR-css3- mediaqueries-20090915, September 2009, <http://www.w3.org/TR/2009/ CR-css3-mediaqueries-20090915/>.
[W3C.CR-CSS3-mediaqueries-20090915] Van Kesteren、A。Glazman、D Lie、H。およびT. Celik、「Media Queries」、W3C Candidate Recommendation CR-css3- mediaqueries-20090915、2009年9月<http://www.w3.org/TR/2009/ CR-CSS3-mediaqueries-20090915 />。
Latest version available at <http://www.w3.org/TR/css3-mediaqueries/>.
<http://www.w3.org/TR/css3-mediaqueries/>で入手可能な最新バージョン。
[W3C.CR-curie-20090116] Birbeck, M. and S. McCarron, "CURIE Syntax 1.0", W3C Candidate Recommendation CR-curie-20090116, January 2009, <http://www.w3.org/TR/2009/CR-curie-20090116>.
[W3C.CR-curie-20090116] Birbeck、M。およびS. McCarron、「CURIE Syntax 1.0」、W3C候補の推奨CR-curie-20090116、2009年1月、<http://www.w3.org/TR/2009 / CR-curie-20090116>。
Latest version available at <http://www.w3.org/TR/curie>.
<http://www.w3.org/TR/curie>で入手可能な最新バージョン。
[W3C.REC-html401-19991224] Le Hors, A., Raggett, D., and I. Jacobs, "HTML 4.01 Specification", W3C Recommendation REC-html401-19991224, December 1999, <http://www.w3.org/TR/1999/REC-html401-19991224>.
[W3C.REC-html401-19991224] Le Hors、A.、Raggett、D。、およびI. Jacobs、「HTML 4.01仕様」、W3C勧告REC-html401-19991224、1999年12月、<http：//www.w3 .org / TR / 1999 / REC-html401-19991224>。
Latest version available at <http://www.w3.org/TR/html401>.
<http://www.w3.org/TR/html401>で入手可能な最新バージョン。
[W3C.REC-rdfa-syntax-20081014] Adida, B., Birbeck, M., McCarron, S., and S. Pemberton, "RDFa in XHTML: Syntax and Processing", W3C Recommendation REC-rdfa-syntax-20081014, October 2008, <http://www.w3.org/TR/2008/REC-rdfa-syntax-20081014>.
[W3C.REC-rdfa-syntax-20081014]アディダ、B。、ビルベック、M。、マッカロン、S。、およびS.ペンバートン、「XHTMLのRDFa：構文および処理」、W3C勧告REC-rdfa-syntax-20081014 、2008年10月、<http://www.w3.org/TR/2008/REC-rdfa-syntax-20081014>。
Latest version available at <http://www.w3.org/TR/rdfa-syntax>.
<http://www.w3.org/TR/rdfa-syntax>で入手可能な最新バージョン。
[W3C.REC-xhtml-basic-20080729] Baker, M., Ishikawa, M., Stark, P., Matsui, S., Wugofski, T., and T. Yamakami, "XHTML[TM] Basic 1.1", W3C Recommendation REC-xhtml-basic-20080729, July 2008, <http://www.w3.org/TR/2008/REC-xhtml-basic-20080729>.
[W3C.REC-xhtml-basic-20080729]ベイカー、M、石川、M、スターク、P、マツイ、S、ウゴフスキー、T、山上、「XHTML [TM] Basic 1.1」、 W3C勧告REC-xhtml-basic-20080729、2008年7月、<http://www.w3.org/TR/2008/REC-xhtml-basic-20080729>。
Latest version available at <http://www.w3.org/TR/xhtml-basic>.
<http://www.w3.org/TR/xhtml-basic>で入手可能な最新バージョン。
HTML motivated the original syntax of the Link header, and many of the design decisions in this document are driven by a desire to stay compatible with these uses.
HTMLはLinkヘッダーの元の構文を動機づけており、このドキュメントの設計上の決定の多くは、これらの使用との互換性を維持したいという願望によって推進されています。
In HTML4, the link element can be mapped to links as specified here by using the "href" attribute for the target URI, and "rel" to convey the relation type, as in the Link header. The context of the link is the URI associated with the entire HTML document.
HTML4では、ターゲットURIの "href"属性を使用してリンク要素をリンクにマッピングし、 "rel"を使用してリンクヘッダーのように関係タイプを伝達できます。リンクのコンテキストは、HTMLドキュメント全体に関連付けられたURIです。
All of the link relation types defined by HTML4 have been included in the Link Relation Type registry, so they can be used without modification. However, there are several potential ways to serialise extension relation types into HTML4, including
HTML4で定義されているすべてのリンク関係タイプは、リンク関係タイプレジストリに含まれているため、変更せずに使用できます。ただし、拡張関係タイプをHTML4にシリアル化するには、いくつかの方法があります。
o As absolute URIs,
o 絶対URIとして、
o using the document-wide "profile" attribute's URI as a prefix for relation types, or
o ドキュメント全体の「プロファイル」属性のURIを関係タイプの接頭辞として使用する、または
o using the RDFa [W3C.REC-rdfa-syntax-20081014] convention of mapping token prefixes to URIs (in a manner similar to XML name spaces) (note that RDFa is only defined to work in XHTML [W3C.REC-xhtml-basic-20080729], but is sometimes used in HTML4).
o RDFa [W3C.REC-rdfa-syntax-20081014]を使用して、トークンプレフィックスをURIにマッピングする（XML名前空間と同様の方法で）（RDFaはXHTML [W3C.REC-xhtml-basic -20080729]ですが、HTML4で使用されることもあります）。
Individual applications of linking will therefore need to define how their extension links should be serialised into HTML4.
したがって、リンクの個々のアプリケーションは、それらの拡張リンクをHTML4にシリアル化する方法を定義する必要があります。
Surveys of existing HTML content have shown that unregistered link relation types that are not URIs are (perhaps inevitably) common. Consuming HTML implementations should not consider such unregistered short links to be errors, but rather relation types with a local scope (i.e., their meaning is specific and perhaps private to that document).
既存のHTMLコンテンツの調査では、URIではない未登録のリンク関係タイプが（おそらく必然的に）一般的であることが示されています。 HTML実装の使用では、このような未登録のショートリンクをエラーと見なすべきではなく、ローカルスコープを持つ関係タイプ（つまり、それらの意味はそのドキュメントに固有で、おそらくプライベートなもの）と見なすべきです。
HTML4 also defines several attributes on links that are not explicitly defined by the Link header. These attributes can be serialised as link-extensions to maintain fidelity.
HTML4は、Linkヘッダーで明示的に定義されていないリンクのいくつかの属性も定義します。これらの属性は、忠実度を維持するためにリンク拡張としてシリアル化できます。
Finally, the HTML4 specification gives a special meaning when the "alternate" and "stylesheet" relation types coincide in the same link. Such links should be serialised in the Link header using a single list of relation-types (e.g., rel="alternate stylesheet") to preserve this relationship.
最後に、HTML4仕様は、「代替」と「スタイルシート」の関係タイプが同じリンクで一致する場合に特別な意味を与えます。このようなリンクは、この関係を維持するために、関係タイプの単一のリスト（例：rel = "alternate stylesheet"）を使用して、Linkヘッダーでシリアル化する必要があります。
Atom conveys links in the atom:link element, with the "href" attribute indicating the target IRI and the "rel" attribute containing the relation type. The context of the link is either a feed IRI or an entry ID, depending on where it appears; generally, feed-level links are obvious candidates for transmission as a Link header.
Atomは、atom：link要素でリンクを伝達します。「href」属性はターゲットIRIを示し、「rel」属性は関係タイプを含みます。リンクのコンテキストは、表示場所に応じて、フィードIRIまたはエントリIDのいずれかです。一般に、フィードレベルのリンクは、リンクヘッダーとしての送信の明確な候補です。
When serialising an atom:link into a Link header, it is necessary to convert target IRIs (if used) to URIs.
atom：linkをLinkヘッダーにシリアル化する場合、ターゲットIRI（使用されている場合）をURIに変換する必要があります。
Atom defines extension relation types in terms of IRIs. This specification re-defines them as URIs, to simplify and reduce errors in their comparison.
AtomはIRIの観点から拡張関係タイプを定義します。この仕様は、それらをURIとして再定義し、比較におけるエラーを簡略化および削減します。
Atom allows registered link relation types to be serialised as absolute URIs. Such relation types SHOULD be converted to the appropriate registered form (e.g., "http://www.iana.org/assignments/relation/self" to "self") so that they are not mistaken for extension relation types.
Atomでは、登録されたリンク関係タイプを絶対URIとしてシリアル化できます。そのような関係タイプは、拡張関係タイプと間違われないように、適切な登録済みフォーム（「http://www.iana.org/assignments/relation/self」から「self」など）に変換する必要があります（SHOULD）。
Furthermore, Atom link relation types are always compared in a case-sensitive fashion; therefore, registered link relation types SHOULD be converted to their registered form (usually, lowercase) when serialised in an Atom document.
さらに、Atomリンクの関係タイプは常に大文字と小文字を区別して比較されます。したがって、登録されたリンク関係タイプは、Atomドキュメントでシリアル化されるときに、登録された形式（通常は小文字）に変換する必要があります（SHOULD）。
Note also that while the Link header allows multiple relations to be serialised in a single link, atom:link does not. In this case, a single link-value may map to several atom:link elements.
また、Linkヘッダーでは複数の関係を1つのリンクでシリアル化できますが、atom：linkではそうできません。この場合、1つのlink-valueが複数のatom：link要素にマッピングされる場合があります。
As with HTML, atom:link defines some attributes that are not explicitly mirrored in the Link header syntax, but they can also be used as link-extensions to maintain fidelity.
HTMLと同様に、atom：linkはLinkヘッダー構文で明示的にミラーリングされない属性を定義しますが、忠実度を維持するためのリンク拡張として使用することもできます。
This specification lifts the idea and definition for the Link header from RFC 2068; credit for it belongs entirely to the authors of and contributors to that document. The link relation type registrations themselves are sourced from several documents; see the applicable references.
この仕様は、RFC 2068からのリンクヘッダーの概念と定義を引き上げています。それのクレジットは、完全にそのドキュメントの作者とその貢献者に帰属します。リンク関係タイプの登録自体は、いくつかのドキュメントから提供されています。該当するリファレンスを参照してください。
The author would like to thank the many people who commented upon, encouraged and gave feedback to this specification, especially including Frank Ellermann, Roy Fielding, Eran Hammer-Lahav, and Julian Reschke.
著者は、特にフランクエラーマン、ロイフィールディング、エランハマーラハブ、ジュリアンレシュケなど、この仕様にコメントし、奨励し、フィードバックを提供してくれた多くの人々に感謝したいと思います。
Author's Address
著者のアドレス
Mark Nottingham
マーク・ノッティンガム
EMail: mnot@mnot.net
URI: http://www.mnot.net/