RFC 8288 — Web Linking（日本語訳）

◎要約

この仕様は、 ~Web上の`資源$間の関係性（ “~link” ）用の~modelと, それらの関係性の型（ “~link関係~型” ）を定義する。 ◎ This specification defines a model for the relationships between resources on the Web (“links”) and the type of those relationships (“link relation types”).

また、そのような~linkの，~HTTP~headerにおける `Link$h ~headerによる直列化も定義する。 ◎ It also defines the serialisation of such links in HTTP headers with the Link header field.

この文書には正誤表がある。 ◎ This document has errata.

1. 序論

この仕様は、 ~Web上の`資源$~間の関係性（ “~link” ）用の~modelと, それらの関係性の型（ “~link関係~型” ）を定義する。 ◎ This specification defines a model for the relationships between resources on the Web (“links”) and the type of those relationships (“link relation types”).

~HTML `W3C.REC-html5-20141028$r, ~Atom `RFC4287$r の両者には、きちんと定義された~link法の概念がある。 `2§ では、これを［これらの形式, 他所にあり得る~link法］を包摂する~frameworkに一般~化する。 ◎ HTML [W3C.REC-html5-20141028] and Atom [RFC4287] both have well-defined concepts of linking; Section 2 generalises this into a framework that encompasses linking in these formats and (potentially) elsewhere.

加えて， `3§ では、そのような~linkを伝達するための~HTTP~headerを定義する。 ◎ Furthermore, Section 3 defines an HTTP header field for conveying such links.

1.1. 表記規約

この文書~内の~keyword "MUST" … 【以下、この段落の内容は`~IETF日本語訳共通~page＠~IETFcommon#requirements-notation$に移譲。】 ◎ 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.

この文書は、 `RFC5234$r による~ABNF, および `HTTP$r による表記を利用する… 【以下、詳細は `~HTTP日本語訳共通~page＠~HTTPcommon#syntax-notation$に移譲。】 `OWS$p, `BWS$p は `HTTP$r に定義される。加えて、 `LOALPHA$P 【英小文字】は次で定義される： ◎ This document uses the Augmented Backus-Naur Form (ABNF) [RFC5234] notation of [RFC7230], including the #rule, and explicitly includes the following rules from it: quoted-string, token, SP (space), BWS (bad whitespace), OWS (optional whitespace), RWS (required whitespace), LOALPHA, DIGIT.

`LOALPHA@P
	= `61-7A^X

【この~ABNFは、 `正誤表 #5319＠~ERRATA/eid5319$（ Reported: 2018-04-04 ）に基づいて追加している — 原文では、 `LOALPHA^P を定義することなく利用していた）。】

加えて，次の規則も含まれる： ◎ Additionally, the following rules are included:

`URI@p, `URI-Reference@p `RFC3986$r ◎ URI and URI-Reference from [RFC3986],
`type-name@p, `subtype-name@p `RFC6838$r ◎ type-name and subtype-name from [RFC6838],
`media-query-list@p `W3C.REC-css3-mediaqueries-20120619$r ◎ media-query-list from [W3C.REC-css3-mediaqueries-20120619], and
`Language-Tag@p `RFC5646$r ◎ Language-Tag from [RFC5646].

【この訳に特有な表記規約】

この訳では、この仕様が公表された当時の~HTTP仕様（ `RFC7230$r, `RFC7231$r ）を参照している箇所を，現在の中核~HTTP仕様 `HTTP$r 内の`等価な記述を指すよう改めている＠~HTTPcommon#_terms-convention$。

1.2. 適合性と~errorの取扱い

`HTTP$r `適合性§【！`7230/2.5$rfc】による適合性と~errorの取扱いに関する要件は、この文書にも適用される。 ◎ The requirements regarding conformance and error handling highlighted in [RFC7230], Section 2.5 apply to this document.

2. ~link

この仕様における `~link^dfn とは、 2 つの`資源$間の繋がりであり，次に挙げるものからなる： ◎ In this specification, a link is a typed connection between two resources and is comprised of:

`~link文脈@ ◎ A link context,
`~link関係~型@ （ `2.1§ ） ◎ a link relation type (Section 2.1),
`~link~target@ ◎ a link target, and
`~target属性~群@ — 0 個以上の`~target属性$からなる ◎ optionally, target attributes (Section 2.2).

`~link$は、次のような形の言明として~~解釈できる ⇒ “`~link文脈$は、 `~link関係~型$の`資源$を有する — その資源は、 `~link~target$に在って，`~target属性~群$を有する” ◎ A link can be viewed as a statement of the form “link context has a link relation type resource at link target, which has target attributes”.

例えば ⇒ `https://www.example.com/^c は、 “正準的な” `資源$を有する — その資源は、 `https://example.com^c に在って， `type^c 属性として `text/html^c を有する。 ◎ For example, “https://www.example.com/” has a “canonical” resource at “https://example.com”, which has a “type” of “text/html”.

`~link文脈$, `~link~target$は、両者とも~IRIである `RFC3987$r 。しかしながら，共通的な事例では、 `~link文脈$は，~URIにもなる `RFC3986$r — 多くの~protocol（~HTTPなど）は、 ~IRIの参照取得-法（ `dereferencing^en ）を~supportしないので。同様に，`~link~target$は、直列化法が~IRIを~supportしない所では（`3§ に定義する `Link$h ~headerなど）， ~URIに変換されることになる（ `3987/3.1$rfc を見よ）。 ◎ Link contexts and link targets are both Internationalized Resource Identifiers (IRIs) [RFC3987]. However, in the common case, the link context will also be a URI [RFC3986], because many protocols (such as HTTP) do not support dereferencing IRIs. Likewise, the link target will sometimes be converted to a URI (see [RFC3987], Section 3.1) in serialisations that do not support IRIs (such as the Link header field defined in Section 3).

この仕様は、 ~linkの個数についての制約は設置しない。特定0の~target［への／からの］~linkは複数あり得るし、所与の`文脈$と`~target$の間には、 `関係~型$が互いに［同じ／異なる］複数の~linkがあり得る。同様に、［特定0の直列化法における~link ／各直列化法（例： `Link$h ~header内や内容~内の~link）］どうしの順序関係は、指定されないし，この仕様においては有意でない — 順序関係を有意と見なしたいと望む応用は、そうすることもできる。 ◎ This specification does not place restrictions on the cardinality of links; there can be multiple links to and from a particular target and multiple links of the same or different types between a given context and target. Likewise, the relative ordering of links in any particular serialisation, or between serialisations (e.g., the Link header field and in-content links), is not specified or significant in this specification; applications that wish to consider ordering significant can do so.

~linkは、 ~link直列化~内に伝達される。それは、 “伝送路~上の~byte列” であり，様々な形で生じ得る。例えば~Atom `RFC4287$r, ~HTML `W3C.REC-html5-20141028$r の両者とも，各自の形式への~linkの直列化法が定義されている。 `3§ では、 ~HTTP~headerにおいて~linkを直列化する方法を定義する。 ◎ Links are conveyed in link serialisations; they are the “bytes on the wire”, and can occur in various forms. For example, Atom [RFC4287] and HTML [W3C.REC-html5-20141028] both defined serialisations of links into their respective formats, and Section 3 defines how to serialise links in HTTP header fields.

この仕様は、異なる直列化法にまたがる~link用の一般~構文は定義しない。また、どの~linkにも，特定の文脈は義務付けない — その両~側面は、各種~linkの直列化法が指定するものと期待されている。 ◎ This specification does not define a general syntax for links across different serialisations, nor does it mandate a specific context for any given link; it is expected that serialisations of links will specify both aspects.

最後に，~linkを利用するのは、 ~link応用である。一般に，応用は、自身が利用する各種 `~link関係~型$を，自身の中で生じ得る各種直列化法とともに定義することになる。例えば、 “~Web閲覧” 応用は，~HTML `link$e 直列化~内（および任意選択で `Link$h ~header内）で `~link関係~型$ `stylesheet$v を探す一方で、 “AtomPub” 応用は，~Atom直列化~内で，~link関係 `edit^c, `edit-media^c を利用する。 ◎ Finally, links are used by link applications. Generally, an application will define the link relation type(s) it uses, along with the serialisation(s) that they might occur within. For example, the application “Web browsing” looks for the “stylesheet” link relation type in the HTML link serialisation (and optionally in the Link header field), whereas the application “AtomPub” uses the “edit” and “edit-media” link relations in the Atom serialisation.

2.1. ~link関係~型

最も単純な事例では、 `~link関係~型$は~linkの意味論を識別する。例えば，関係~型 `copyright^c を伴う~linkは、［現在の`~link文脈$は、 `~link~target$に在る，“著作権（ `copyright^en ）” `資源$を有する］ことを指示する。 ◎ 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 current link context has a copyright resource at the link target.

`~link関係~型$は［ ~target`資源$が特定0の［属性を有する, または挙動を呈する］もの］と指示するためにも利用できる — 例えば， `service^c ~linkは、［ `~link~target$は，ある定義-済み~protocol（この事例では `service description^en ）の一部として利用できる］ことを含意する。 ◎ 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 link target can be used as part of a defined protocol (in this case, a service description).

関係~型を`~MIME型$（ `media type^en ） `RFC2046$r と混同しないように — 関係~型は、 ~linkを参照取得した結果の`表現$の形式は識別しない。関係~型が述べるのは、現在の文脈が別の`資源$にどう関係するかに限られる。 ◎ Relation types are not to be confused with media types [RFC2046]; 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.

関係~型から［［それが生じた個数, 別の`~link関係~型$の有無］に基づくような，追加的な意味論］は、推定されるベキでない。これに対する例外は，`登録-済み関係~型$［ `alternate$v, `stylesheet$v ］の組合nであり、歴史的な理由から，~HTMLにおいては特別な意味がある。 ◎ 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 HTML for historical reasons.

関係~型には、次の 2 種類がある ⇒＃ `登録-済み関係~型$, `拡張~関係~型$ ◎ There are two kinds of relation types: registered and extension.

2.1.1. 登録-済み関係~型

きちんと定義された（ `well-defined^en ）関係~型は — 便利~用に／他の応用による再利用を~~促すために — `2.1.1.1§ における手続-を利用して，~tokenとして登録できる。 ◎ Well-defined relation types can be registered as tokens for convenience and/or to promote reuse by other applications, using the procedure in Section 2.1.1.1.

登録-済み関係~型の名前は： ◎ Registered relation type names＼

`reg-rel-type$p 規則に適合しなければナラナイ（ `3.3§ を見よ） ◎ MUST conform to the reg-rel-type rule (see Section 3.3) and＼
文字大小無視で文字ごとに比較されなければナラナイ。 ◎ MUST be compared character by character in a case-insensitive fashion.＼
関係~型の特有さに適切になるベキである — すなわち，その意味論が特定0の応用にきわめて特有な場合、名前はそれを反映するべきである — より一般的な名前が，より特有でない用途に可用になるよう。 ◎ They SHOULD be appropriate to the specificity of the relation type; that is, 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.

登録-済み関係~型は、［ `~link文脈$の`~MIME型$ ／ `~link~target$に可用な`表現$の`~MIME型$ ］を拘束してはナラナイ。しかしながら、 ~target`資源$の挙動や特質は，指定できる（例：許容-可能な~HTTP~method, ［要請／応答］にて~supportが要求される`~MIME型$）。 ◎ Registered relation types MUST NOT constrain the media type of the link context and MUST NOT constrain the available representation media types of the link target. However, they can specify the behaviours and properties of the target resource (e.g., allowable HTTP methods, and request and response media types that are required be supported).

歴史的に，登録-済み関係~型は、 ~URI `RFC3986$r で識別されてきた — その名前に応用~定義な基底~URIを接頭することにより（例： `A.2§ を見よ）。この実施は、 `推奨されない^2119 — 何故なら、他の応用は，結果の文字列を登録-済み関係~型と等価と見なさなくなるので。その種の~URIを内部に利用しない応用は、［それを収容するものと明示的に~~定めない，~link直列化］内にそれを利用してはナラナイ。 ◎ Historically, registered relation types have been identified with a URI [RFC3986] by prefixing their names with an application-defined base URI (e.g., see Appendix A.2). This practice is NOT RECOMMENDED, because the resulting strings will not be considered equivalent to the registered relation types by other applications. Applications that do use such URIs internally MUST NOT use them in link serialisations that do not explicitly accommodate them.

2.1.1.1. ~link関係~型の登録-法

`~link関係~型$の登録~要請は、次のいずれかにより為せる ⇒＃ `~link関係~型~registry$citeによる指示書きに従う／ link-relations@ietf.org ~mailing-listに~emailを送信する ◎ The “Link Relations” registry is located at “https://www.iana.org/assignments/link-relations/”. Registration requests can be made by following the instructions located there or by sending an email to the “link-relations@ietf.org” mailing list.

`~link関係~型$の登録~要請は、少なくとも次に挙げる情報からなる： ◎ Registration requests consist of at least the following information:

`Relation Name^en: 当の関係~型の名前。 ◎ The name of the relation type
`Description^en: 当の関係~型の意味論についての，英語による短い記述。 `~link文脈$と`~link~target$との関係性の用語で言明されるベキである。 ◎ A short English description of the type’s semantics. It SHOULD be stated in terms of the relationship between the link context and link target.
`Reference^en: 当の関係~型を指定する文書への参照 — 文書の複製を検索取得するために利用できる~URIを含めることが好ましい。関連な節も，要求されてはいないが指示できる。 ◎ Reference to the document that specifies the link relation type, preferably including a URI that can be used to retrieve a copy of the document. An indication of the relevant section(s) can also be included but is not required.

`専門家$は、 ~registry内に収集されることになる追加的な~fieldを定義できる。 ◎ The expert(s) can define additional fields to be collected in the registry.

登録-済み関係~型~用の一般~要件は、 `2.1.1§ にて述べる。 ◎ General requirements for registered relation types are described in Section 2.1.1.

登録は、自由に可用かつ安定的な仕様を参照しなければナラナイ。 ◎ Registrations MUST reference a freely available, stable specification.

`関係~型$は、第三者-主体により登録できる／され得ることに注意（`専門家$も含めて） — `専門家$が［登録されてない`関係~型$が広く配備されていて，適時に登録されると見込まれない］と決定する場合には。そのような登録は、依然として，定義された要件の~subjectになる — 何らかの仕様を参照する必要も含め。 ◎ Note that relation types can be registered by third parties (including the expert(s)), if the expert(s) determines that an unregistered relation type is widely deployed and not likely to be registered in a timely manner otherwise. Such registrations still are subject to the requirements defined, including the need to reference a specification.

2.1.1.2. 登録~要請の過程

`関係~型$は、 `Specification Required^en 【 “仕様~化が要求される” 】施策（ `8126/4.6$rfc ）を利用して登録される。それは、ある指名された一人~以上の `専門家@ による考査と認可を含意する。 ◎ Relation types are registered using the Specification Required policy (see Section 4.6 of [RFC8126]), which implies review and approval by a designated expert.

~registryの目標は、 ~Internet上での~linkの共通的な利用を反映することである。したがって，`専門家$は、当の~linkが次に該当する場合を除き，登録を認可する方へ向けて強く肩入れするべきである： ◎ The goal of the registry is to reflect common use of links on the Internet. Therefore, the expert(s) should be strongly biased towards approving registrations, unless＼

濫用的である ◎ they are abusive,＼
軽率である ◎ frivolous,＼
~Internet上で利用されるものと見込まれない ◎ not likely to be used on the Internet, or＼
それ自体が~Internetや~Webに有害である（単に［審美的に不快である／~architecture的に疑わしい］ではなく） ◎ actively harmful to the Internet and/or the Web (not merely aesthetically displeasing or architecturally dubious).＼

`2.1.1§ に言明したように，`専門家$は、提案された応用~用には一般的~過ぎる名前の登録を差止めれる。 ◎ As stated in Section 2.1.1, the expert(s) can withhold registration of names that are too general for the proposed application.

`専門家$は、登録を拒否させるような課題があれば，それを明瞭に特定すること。提案された`~link関係~型$の意味論について助言を与えれるが、登録を阻止しない場合には，その助言は明示的に言明されるべきである。 ◎ The expert(s) will clearly identify any issues that cause a registration to be refused. Advice about the semantics of a proposed link relation type can be given, but if it does not block registration, this should be explicitly stated.

`専門家$は、ある要請を認可したときには，そのことを~IANAに伝えること — それにより，登録は処理されることになる。異議がある場合の最終~裁定者は、 IESG である。 ◎ When a request is approved, the expert(s) will inform IANA, and the registration will be processed. The IESG is the final arbiter of any objection.

2.1.2. 拡張~関係~型

`関係~型$を登録したいと望まない応用は、 `拡張~関係~型^dfn を利用できる。それは`関係~型$を一意に識別する~URI `RFC3986$r である。 ~URIは，`関係~型$の意味論の定義を包含する`資源$を~~指せるが、 ~clientは — ~serverにとって~~過度の重荷になるのを避けるため — その資源に自動的に~accessするベキでない。 ◎ 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は、それを定義しているか委任された［個人または主体］の制御~下に置かれるベキである。 ◎ The URI used for an extension relation type SHOULD be under the control of the person or party defining it or be delegated to them.

拡張~関係~型どうしが比較されるときは、文字列として — 文字大小無視で, 文字ごとに — 比較されなければナラナイ（~URIでない形式に直列化されている場合は，~URIに変換した上で）。拡張~関係~用には、すべて小文字にされた~URIが利用されるベキなので。 ◎ When extension relation types are compared, they MUST be compared as strings (after converting to URIs if serialised in a different format) in a case-insensitive fashion, character by character. Because of this, all-lowercase URIs SHOULD be used for extension relations.

拡張~関係~型は，~URIにすることが要求されるが、 ~linkの直列化法は — ~URIに変換できる限りにおいて — 別の形で表出するものと指定できることに注意。 ◎ 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.

2.2. ~target属性

`~target属性~群$は、一連の［ ~key, 値］~pairからなる~listである。この~listを成す各~pairは、 `~target属性@ と呼ばれ，`~link$またはその`~target$について述べる — 例えば、 ~MIME型~hint。 ◎ Target attributes are a list of key/value pairs that describe the link or its target; for example, a media type hint.

個々の［ `~link関係~型$／~link直列化法］は、それらを定義し得る。 ◎ They can be defined both by individual link relation types and by link serialisations.

この仕様は、 `~target属性$の［名前／個数／利用］について，協調しようと試みるものではない。直列化法を［作成-／保守- ］している者は、意味論や構文における競合を避けるため，それらの~target属性を協調するベキである — また，~target属性~用に自前の~registryを定義してもヨイ。 ◎ This specification does not attempt to coordinate the name of target attributes, their cardinality, or use. Those creating and maintaining serialisations SHOULD coordinate their target attributes to avoid conflicts in semantics or syntax and MAY define their own registries of target attributes.

~target属性の名前は、 `token$p 規則に適合するベキであるが、各種直列化法にまたがる~port能を得るため，文字［ `%^c, `’^c, `*^c ］を内包するベキでない。また、文字大小無視で比較されなければナラナイ。 ◎ The names of target attributes SHOULD conform to the token rule, but SHOULD NOT include any of the characters “%”, “’”, or “*”, for portability across serialisations and MUST be compared in a case-insensitive fashion.

~target属性~定義は、次を指定するベキである： ◎ Target attribute definitions SHOULD specify:

各種~link直列化法にまたがる~port能の機会cを最大化するため、その値を［ ~Unicodeまたはその下位集合］に直列化する~~方法。 ◎ The serialisation of their values into Unicode or a subset thereof, to maximise their chances of portability across link serialisations.
所与の`~link$内に【同じ名前の】~target属性が複数個ある場合の，意味論と~errorの取扱い ◎ The semantics and error handling of multiple occurrences of the target attribute on a given link.

この仕様は、 `3.4§ にて， `Link$h ~HTTP~header内で利用するための各種~target属性を定義する。 ◎ This specification does define target attributes for use in the Link HTTP header field in Section 3.4.

3. ~HTTP~headerにおける~link直列化法

`Link@h ~headerが、 1 個~以上の`~link$を~HTTP~headerの中へ直列化する手段を供する。 ◎ The Link header field provides a means for serialising one or more links into HTTP headers.

その`~field値$用の~ABNFは： ◎ The ABNF for the field value is:

`Link@p
	= #`link-value$p
`link-value@p
	= "<" `URI-Reference$p ">" *( `OWS$p ";" `OWS$p `link-param$p )
`link-param@p
	= `token$p `BWS$p [ "=" `BWS$p ( `token$p / `quoted-string$p ) ]

どの `link-param$p を`生成-$するときにも、［ `~token形@ （ `token$p ）, `引用符d形@ （ `quoted-string$p ）］どちらの構文も利用できることに注意。したがって，`受信者$は、両~形とも構文解析-可能でなければナラナイ。例えば， 2 つの~parameter［ `x=y^c ］, ［ `x="y"^c ］は、等価になる。 ◎ Note that any link-param can be generated with values using either the token or the quoted-string syntax; therefore, recipients MUST be able to parse both forms. In other words, the following parameters are equivalent: • x=y • x="y"

`Link^h ~headerの以前の定義は、［ `~token形$, `引用符d形$ ］を明示的に~~等しく~~扱ってなかった。 `title^c ~parameterは常に`引用符d形$にされ、 `hreflang^c ~parameterは常に`~token形$であった。相互運用能を最大化したいと望む送信者は、それらをそのような形で送信することになる。 ◎ Previous definitions of the Link header did not equate the token and quoted-string forms explicitly; the title parameter was always quoted, and the hreflang parameter was always a token. Senders wishing to maximize interoperability will send them in those forms.

個々の `link-param$p は、その構文を，【値を構文解析する前に】必要yな［引用符を（ `HTTP$r `引用符~付き文字列＠~HTTPinfra#quoted.strings§【！`7230/3.2.6$rfc】に従って）外した後の値］に基づいて指定する。 ◎ Individual link-params specify their syntax in terms of the value after any necessary unquoting (as per [RFC7230], Section 3.2.6).

この仕様は、 `link-param$p として，次に挙げるものを確立する：

`rel^c, `anchor^c, `rev^c （これらは、一般~link~modelの一部を成す）
`hreflang^c, `media^c, `title^c, `title*^c, `type^c （これらは、 `Link$h 直列化法により定義される`~target属性$【 `3.4.1§ 】である）

◎ This specification establishes the link-params “rel”, “anchor”, and “rev” (which are part of the general link model), as well as “hreflang”, “media”, “title”, “title*”, and “type” (which are target attributes defined by the serialisation).

3.1. ~link~target

各 `link-value$p は、 1 個の~target~IRIを，山括弧（ `<>^c ）で括られた `URI-Reference$p として伝達する（必要yなら，~URIに変換した上で — `3987/3.1$rfcを見よ）。 `URI-Reference$p が相対的な場合、構文解析器は `3986/5$rfc に従ってそれを解決しなければナラナイ。 ~messageの内容~内に出現しているどの基底~IRIも，適用されないことに注意。 ◎ 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 appearing in the message’s content is not applied.

3.2. ~link文脈

既定では、 `Link$h ~header内に伝達される`~link$の`文脈$は — `HTTP$r `内容の識別-法＠~HTTPinfra#identifying.content§【！`7231/3.1.4.1$rfc 】にて定義されるように — それ【当の`~message$】に結付けられる`表現$の~URLになり，~URIとして直列化される。 ◎ By default, the context of a link conveyed in the Link header field is the URL of the representation it is associated with, as defined in [RFC7231], Section 3.1.4.1, and is serialised as a URI.

`anchor^c ~parameterが在るときは、これ（表現の~URL）を別の~URI — この`資源$の素片や，第三の資源（すなわち、この~parameterの値は絶対~URIであるとき）など — で上書きする。この~parameterの値が相対~URIである場合、構文解析器は `3986/5$rfc に従って，それを解決しなければナラナイ。 `~message$の`内容$【！本体の内容】からの基底~URI【例： ~HTML `base$e 要素により指定されるそれなど】は、在っても適用されないことに注意。 ◎ 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.

`anchor^c ~parameterの値~用の~ABNFは： ◎ The ABNF for the anchor parameter’s value is:

`URI-Reference$p ; `3986/4.1$rfc

~link応用は、 `anchor^c ~parameterを伴う`~link$を無視することを選択できる。例えば，利用中の応用は、 `~link文脈$が異なる`資源$にアテガわれることを許容しないかもしれない。そのような事例では、 ~link全体が無視されることになる — ~link応用は、 `~link$を処理するならば `anchor^c を適用しなければナラナイ。 ◎ Link application can choose to ignore links with an anchor parameter. For example, the application in use might not allow the link context to be assigned to a different resource. In such cases, the entire link is to be ignored; link applications MUST NOT process the link without applying the anchor.

~HTTP`状態s~code$と`応答~header$に依存して， `~link文脈$は “匿名” （すなわち，`~link文脈$は可用でない）にもなり得ることに注意。該当する例として、 `GET$m 要請に対する `404$st0 応答が挙げられる。 ◎ Note that depending on HTTP status code and response headers, the link context might be “anonymous” (i.e., no link context is available). For example, this is the case on a 404 response to a GET request.

3.3. 関係~型

`Link$h ~header内に伝達される`~link$の`関係~型$は、 `rel^c ~parameterの値~内に伝達される。 `rel^c ~parameterは在ることが`要求される^2119が、所与の `link-value$p 内に複数回~出現してはナラナイ — 構文解析器は、最初を除くすべてのそれを無視しなければナラナイ。 ◎ The relation type of a link conveyed in the Link header field is conveyed in the “rel” parameter’s value. The rel parameter MUST be present but MUST NOT appear more than once in a given link-value; occurrences after the first MUST be ignored by parsers.

しかしながら， `rel^c ~parameterは、複数の`~link関係~型$を包含できる。これが生じたときは、同じ［ `文脈$, `~target$, `~target属性~群$ ］を共有する複数の`~link$を確立する。 ◎ The rel parameter can, however, contain multiple link relation types. When this occurs, it establishes multiple links that share the same context, target, and target attributes.

`rev^c ~parameterは、［関係性の意味論は逆向きである］ことを指示するために過去に利用されていた。すなわち， `rel=X^c を伴う A から B への`~link$は、 `rev=X^c を伴う B から A への`~link$と同じ関係性を表出する。 `rev^c は、この仕様により非推奨にされた — 作者からも読者からも混同されることが多いので。ほとんどの事例では、別々な`関係~型$を利用する方が選好される。 ◎ 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.

`rel^c ／ `rev^c ~parameterの値~用の~ABNFは： ◎ The ABNF for the rel and rev parameters’ values is:

`relation-type$p *( 1*`SP$P `relation-type$p )

ここで： ◎ where:

`relation-type@p
	= `reg-rel-type$p / `ext-rel-type$p
`reg-rel-type@p
	= `LOALPHA$P *( `LOALPHA$P / `DIGIT$P / "." / "-" )
`ext-rel-type@p
	= `URI$p ; `3986/3$rfc

`拡張~関係~型$（ `ext-rel-type$p ）は、 `Link$h ~headerにおいては，絶対~URI【 `absolute-URI$p ？】にすることが`要求される^2119。加えて、 `~token形$に許容されない文字を包含するときは，`引用符d形$でなければナラナイことに注意 — ~semicolon（ `;^c ）や~comma（ `,^c ）など（これらの文字は~field値における区切子として利用されるので）。 ◎ Note that extension relation types are REQUIRED to be absolute URIs in Link header fields and MUST be quoted when they contain characters not allowed in tokens, such as a semicolon (“;”) or comma (“,”) (as these characters are used as delimiters in the header field itself).

3.4. ~target属性

`Link$h ~headerは、この直列化法に特有な，いくつかの`~target属性$を定義し、拡張~target属性も許容する。 ~target属性は、 `Link$h ~header内に `parameter$p `HTTP$r として直列化される。【！（それらの構文の定義は `7231/3.1.1.1$rfcを見よ）】 ◎ The Link header field defines several target attributes specific to this serialisation and also allows extension target attributes. Target attributes are serialised in the Link header field as parameters (see [RFC7231], Section 3.1.1.1 for the definition of their syntax).

3.4.1. 直列化法により定義される属性

以下に挙げる `link-param$p — `hreflang^c, `media^c, `title^c, `title*^c, `type^c — は、 ~link用の直列化法により定義される`~target属性$に翻訳できる。 ◎ The “hreflang”, “media”, “title”, “title*”, and “type” link-params can be translated to serialisation-defined target attributes for the link.

`hreflang^c

この属性が在るときは，［ `~link$を参照取得した結果の言語は何になるべきか］を指示する~hintを与える。これは~hintでしかないことに注意 — 例えば、 `~link$を実際に追って得された~HTTP応答の `Content-Language$h ~headerを上書きすることはない。同じ `link-value$p 上に複数の `hreflang^c 属性が在る場合、指示されている`資源$から複数の言語が可用であることを指示する。 ◎ The “hreflang” attribute, 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 field of a HTTP response obtained by actually following the link. Multiple hreflang attributes on a single link-value indicate that multiple languages are available from the indicated resource.

`hreflang^c ~parameterの値の~ABNFは： ◎ The ABNF for the hreflang parameter’s value is:

`Language-Tag$p

`media^c

この属性が在るときは，［意図される行先~media ／ ~style情報~用の~media ］を指示するために利用される（ ~HTMLの § `link$e 要素を見よ【！[W3C.REC-html5-20141028], Section 4.2.4】【！https://www.w3.org/TR/2014/REC-html5-20141028/document-metadata.html#the-link-element】）。その値は、 ~semicolon（ `;^c ）や~comma（ `,^c ）を包含する場合には，`引用符d形$にされなければナラナイ。 `link-value$p 内に複数個の `media^c 属性があってはナラナイ — 構文解析器は、最初を除くすべてのそれを無視しなければナラナイ。 ◎ The “media” attribute, when present, is used to indicate intended destination medium or media for style information (see [W3C.REC-html5-20141028], Section 4.2.4). Its value MUST be quoted if it contains a semicolon (“;”) or comma (“,”). There MUST NOT be more than one media attribute in a link-value; occurrences after the first MUST be ignored by parsers.

`media^c ~parameterの値~用の~ABNFは： ◎ The ABNF for the media parameter’s value is:

`media-query-list$p

`title^c

この属性が在るときは，［ `~link$の行先をヒトが読める識別子として~labelする］ために利用される（例：~menuの~entry） — その言語は、 `Content-Language$h ~headerにより指示される（在るならば）。 `title^c 属性は、所与の~link内に，複数回~出現してはナラナイ — 構文解析器は、最初を除くすべてのそれを無視しなければナラナイ。 ◎ The “title” attribute, 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 field (if present). The title attribute MUST NOT appear more than once in a given link; occurrences after the first MUST be ignored by parsers.

`title*^c

この `link-param$p は、 `title^c 属性を — `RFC8187$r に従って — ［異なる文字~集合で／異なる言語~情報を包含するように］符号化するために利用できる。 `title*^c は、所与の `link-value$p 内に複数回~出現してはナラナイ — 構文解析器は、最初を除くすべてのそれを無視しなければナラナイ。属性が言語~情報を包含しない場合、それの言語は， `Content-Language$h ~headerにより指示される（在るならば）。【名前の末尾の `*^c は、 “複数” ではなく， “変種である” ことを~~表す。】 ◎ The “title*” link-param can be used to encode this attribute in a different character set and/or contain language information as per [RFC8187]. The title* link-param MUST NOT appear more than once in a given link-value; occurrences after the first MUST be ignored by parsers. If the attribute does not contain language information, its language is indicated by the Content-Language header field (when present).

~link内に［ `title^c, `title*^c ］両 `link-param$p が出現する場合、応用は， `title*^c の値を `title^c 属性~用に利用するベキである。 ◎ If both the title and title* link-params appear in a link, applications SHOULD use the title* link-param’s value for the title attribute.

`type^c

この属性が在るときは，［ `~link$を参照取得した結果の`~MIME型$は何になるべきか］を指示する~hintを与える。これは~hintでしかないことに注意 — 例えば、 `~link$を実際に追って得された~HTTP応答の `Content-Type$h ~headerを上書きすることはない。 `type^c 属性は、所与の `link-value$p 内に複数回出現してはナラナイ — 構文解析器は、最初を除くすべてのそれを無視しなければナラナイ。 ◎ The “type” attribute, 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 field of a HTTP response obtained by actually following the link. The type attribute MUST NOT appear more than once in a given link-value; occurrences after the first MUST be ignored by parsers.

`type^c ~parameterの値~用の~ABNFは： ◎ The ABNF for the type parameter’s value is:

`type-name$p "/" `subtype-name$p ; `6838/4.2$rfc

3.4.2. 拡張~属性

他の `link-param$p は~link拡張であり、 `~target属性$と見なされることになる。 ◎ Other link-params are link-extensions and are to be considered as target attributes.

そのような`~target属性$は、 `RFC8187$r における符号化法を利用するものと定義してもヨイ（例： `example^c と `example*^c ）。両~形とも在るときは、同じ`~target属性$になるものと見なされるベキである — 応用は，名前が `*^c で終端する方の値を（ `RFC8187$r に則って復号した上で）利用するベキであるが、［復号する際に~errorがある／復号を~supportしない］場合には，他の値に~fall-backしてヨイ。 ◎ Such target attributes MAY be defined to use the encoding in [RFC8187] (e.g., “example” and “example*”). When both forms are present, they SHOULD be considered to be the same target attribute; applications SHOULD use the value of the name ending in “*” (after [RFC8187] decoding) but MAY fall back to the other value if there is an error in decoding it, or if they do not support decoding.

3.5. `Link$h ~headerの例

【読みやすくするため、以下の~code例では，`~field行l値$を折返して字下げしているが、（~HTTP11における）そのような折返し構文は廃用にされたことに注意（ `obs-fold$p を見よ）。】

例えば，次のものは： ◎ For example:

Link: <http://example.com/TheBook/chapter2>;
      rel="previous";
      title="previous chapter"

次を指示する ⇒ `chapter2^c は、論理的な~navi順路において，この`資源$の一つ前の資源である。 ◎ indicates that “chapter2” is previous to this resource in a logical navigation path.

類似に，次のものは： ◎ Similarly,

Link: </>;
      rel="http://example.net/foo"

次を指示する ⇒ ~root資源（ `/^c ）は、 `拡張~関係~型$ `http://example.net/foo^c であり，この`資源$に関係している。 ◎ indicates that the root resource (“/”) is related to this resource with the extension relation type “http://example.net/foo”.

次の~linkは： ◎ This link:

Link: </terms>;
      rel="copyright";
      anchor="#foo"

次を指示する ⇒ ~link先の “著作権条項（ `copyright terms^en ）” は、文書の［素片~識別子 `foo^c により指示される，（`~MIME型$に特有な）部位］に限り適用される。 ◎ indicates that the linked copyright terms only apply to the portion of the document indicated by the (media type-specific) fragment identifier “foo”.

次の例では、 1 個の `Link^h ~header内に複数の~linkが符号化されている。また、［非~ASCII文字, 言語~情報］の両者を符号化する［ ~RFC 8187 による符号化法］の利用も示している： ◎ The example below shows an instance of the Link header field encoding multiple links and also the use of the encoding from RFC 8187 to encode both non-ASCII characters and language information.

Link: </TheBook/chapter2>;
      rel="previous";
      title*=`UTF-8'de'letztes%20Kapitel^,
      </TheBook/chapter4>;
      rel="next";
      title*=`UTF-8'de'n%c3%a4chstes%20Kapitel^

ここで、両~linkとも `title^c は~UTF-8に符号化され，両者とも~German（ `de^c ）を利用する。また、 2 個目の~linkは ~Unicode符号位置 U+00E4 LATIN SMALL LETTER A WITH DIAERESIS を包含する。 ◎ Here, both links have titles encoded in UTF-8, both use the German language (“de”), and the second link contains the Unicode code point U+00E4 (“LATIN SMALL LETTER A WITH DIAERESIS”).

`link-value$p は、同じ［ `~link~target$, `~link文脈$ ］の間で複数の`~link$を伝達できることに注意。例えば： ◎ Note that link-values can convey multiple links between the same link target and link context; for example:

Link: <http://example.org/>;
      rel="start http://example.net/relation/other"

ここでは、 `http://example.org/^c への~linkには［ `登録-済み関係~型$ `start^c, `拡張~関係~型$ `http://example.net/relation/other^c ］がある。 ◎ Here, the link to “http://example.org/” has the registered relation type “start” and the extension relation type “http://example.net/relation/other”.

最後に，次の~headerは： ◎ Finally, this header field:

Link: <https://example.org/>;
      rel="start",
      <https://example.org/index>;
      rel="index"

次と等価になる： ◎ is equivalent to these:

Link: <https://example.org/>;
      rel="start"
Link: <https://example.org/index>;
      rel="index"

4. ~IANA考慮点

4.1. `Link^h ~HTTP~headerの登録

この仕様は、 ~HTTP “`Message Headers^en” ~registry `RFC3864$r における `Link$h 用の~entry内の参照を，この文書 RFC 8288 を指すように更新する。 ◎ This specification updates the “Message Headers” registry entry for “Link” in HTTP [RFC3864] to refer to this document. • Header Field Name: Link • Protocol: http • Status: standard • Reference: RFC 8288

4.2. ~link関係~型~registry

この仕様は、 “`Link Relation Types^en （`~link関係~型$）” ~registryの登録~手続-を更新する — `2.1.1.1§ を見よ。また、その~registryにおける RFC 5988 への参照は，すべてこの文書への参照に置換された。 ◎ This specification updates the registration procedures for the “Link Relation Types” registry; see Section 2.1.1.1. Also, all references to RFC 5988 in that registry have been replaced with references to this document.

~IANAは、この~registryに関して寄せられた要請を［この文書, および `専門家$により確立された過程が定義された場合にはそこ］へ指向けることになる。このことは，概して、それが~registry~Web~pageを指すようにすることを意味する。 ◎ IANA will direct any incoming requests regarding the registry to this document and, if defined, the processes established by the expert(s); typically, this will mean referring them to the registry Web page.

`専門家$には、［［［［追加的な~fieldは、（ `2.1.1.1§ に従って）~registry内に収集される］ことになる］ようにする］ものと定義する］ことも許容される。 ◎ Note that the expert(s) is allowed (as per Section 2.1.1.1) to define additional fields to be collected in the registry.

4.3. ~link関係~応用~data~registry

この仕様に従って，~IANAは “`Link Relation Application Data^en （~link関係~応用~data）” ~registryを除去した — それは、利用されておらず，将来も利用されないと見越されるので。 ◎ Per this specification, IANA has removed the “Link Relation Application Data” registry, as it has not been used, and future use is not anticipated.

5. ~securityの考慮点

`Link$h ~headerの内容は［ ~secure ／私的／完全性が保証されるもの］ではない。現在，端点間でこれらの特質を供するための仕方は、 ~HTTPを~TLS越しに利用する `RFC2818$r 他にない。 ◎ The content of the Link header field is not secure, private, or integrity-guaranteed. Use of Transport Layer Security (TLS) with HTTP [RFC2818] is currently the only end-to-end way to provide these properties.

~link応用は、 ~HTTP~headerから集めた`~link$を［自動的に追う／信用する／その他~利用する］ことは，攻撃~行路を開くものと見なす~OUGHT。 ◎ Link applications ought to consider the attack vectors opened by automatically following, trusting, or otherwise using links gathered from HTTP header fields.

例えば，［ `~link文脈$を別の`資源$に結付けるために `anchor^c ~parameterを利用する `Link$h ~header ］は、信用できない — それらは、実質的に［不正／悪意的］な第三者-主体による表明にもなり得るので。応用は、［そのような`~link$は — 当の`資源$の間に何らかの関係性が確立されない限り（例：それらは同じ権限を共有している） — 破棄されるべきである］と指定することにより，この~riskを軽減できる。 ◎ For example, Link header fields that use the “anchor” parameter to associate a link’s context with another resource cannot be trusted since they are effectively assertions by a third party that could be incorrect or malicious. Applications can mitigate this risk by specifying that such links should be discarded unless some relationship between the resources is established (e.g., they share the same authority).

`~link$を参照取得することには、利用-中な応用に依存して，いくつもの~riskがある。例えば， `Referer$h ~header `HTTP$r は、その値~内に，応用の状態についての情報（私的~情報も含む）を公開し得る。同様に， `Cookie$h `RFC6265$r は、攻撃~行路にも利用され得るような別の仕組みである。応用は、そのような仕組みがどう運用されるべきか注意深く指定することにより，これらの~riskを軽減できる。 ◎ Dereferencing links has a number of risks, depending on the application in use. For example, the Referer header [RFC7231] can expose information about the application’s state (including private information) in its value. Likewise, cookies [RFC6265] are another mechanism that, if used, can become an attack vector. Applications can mitigate these risks by carefully specifying how such mechanisms should operate.

`Link$h ~headerは、 ~IRIや~URIを多方面に利用する。［ ~IRI ／~URI／~HTTP~header ］に関係する~securityの考慮点については、次に挙げる各~節を見よ ⇒＃ `3987/8$rfc, `3986/7$rfc, `HTTP$r `~securityの考慮点＠~HTTPinfra#security.considerations§【！`7230/9$rfc】 ◎ The Link header field makes extensive use of IRIs and URIs. See [RFC3987], Section 8 for security considerations relating to IRIs. See [RFC3986], Section 7 for security considerations relating to URIs. See [RFC7230], Section 9 for security considerations relating to HTTP header fields.

6. 国際-化にあたっての考慮点

`~link~target$は、直列化法が~IRIを~supportしない下では，~URIに変換して表出する必要もあり得る。これには `Link$h ~HTTP~headerも含まれる。 ◎ Link targets 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 field.

類似に， `Link$h ~headerの `anchor^c ~parameterは、 ~IRIを~supportしないので，そこに含める前に~URIに変換されなければならない。 ◎ Similarly, the anchor parameter of the Link header field does not support IRIs; therefore, IRIs must be converted to URIs before inclusion there.

`関係~型$は、比較し易くするため，~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.

`登録-済み関係~型$の名前は、小文字~ASCII英字にすることが要求されることに注意。 ◎ Note that registered Relation Names are required to be lowercase ASCII letters.

A. 他の~link直列化法に関する注記

`Link$h ~headerは、 `~link$の直列化法の一種に過ぎない。代替の直列化法を定義している仕様は、他にもある。 ◎ Header fields (Section 3) are only one serialisation of links; other specifications have defined alternative serialisations.

A.1. ~HTMLにおける~link直列化法

元の `Link$h ~header構文は，~HTMLが動機にあり、この文書における設計~上の裁定の多くは，それに互換であり続けようと欲されることによる。 ◎ HTML motivated the original syntax of the Link header field, and many of the design decisions in this document are driven by a desire to stay compatible with it.

~HTMLにおいては、 `link$e 要素を［その `href$a 属性を~target~URI用に利用し，その `rel$a 属性を［ `Link$h ~header内の `rel^c のように`関係~型$を伝達するもの］］として，ここに指定される`~link$に対応付けれる。 ~linkの`文脈$は、 ~HTML文書~全体に結付けられる~URIである。 ~HTMLが~link上に定義する他のいくつかの属性 — `media$a, `hreflang$a, `type$a, `sizes$a など — も，`~target属性$として見れる。 ◎ In HTML, 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 field. The context of the link is the URI associated with the entire HTML document. HTML also defines several attributes on links that can be seen as target attributes, including “media”, “hreflang”, “type”, and “sizes”.

~HTMLの `~link＠~HTMLlinks#links§ 【！[W3C.REC-html5-20141028] 4.8】【！https://www.w3.org/TR/2014/REC-html5-20141028/links.html#links】は、現代の~HTML~linkを定義する。その文書は、 ~registryとして Microformats Wiki へ~linkする。 ~IANA~registryは、時を経て，その内容を~~反映する~OUGHT — 理想的には、それを最終的に置換するよう（それは~HTML~communityに依存するが）。 ◎ Section 4.8 of HTML5 [W3C.REC-html5-20141028] defines modern HTML links. That document links to the Microformats Wiki as a registry; over time, the IANA registry ought to mirror its contents and, ideally, eventually replace it (although that depends on the HTML community).

既存の~HTML内容の調査から，登録-済みでない`~link関係~型$のうち，~URIでないものが（たぶん不可避に）共通的にあることが示された。そのような登録-済みでない短い~linkを消費している~HTML実装は、それを~errorと見なすことなく，`関係~型$の視野は局所的（すなわち、それらの意味は当の文書に特有であり，たぶん私的なものである）と見なす~OUGHT。 ◎ Surveys of existing HTML content have shown that unregistered link relation types that are not URIs are (perhaps inevitably) common. Consuming HTML implementations ought 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仕様は、 `alternate$v `関係~型$が同じ~link内の他の`関係~型$に一致するときに，特別な意味を与える。この関係性を保全するため、 `Link$h ~header内では，そのような~linkたちを一連の `relation-type$p からなる単独の~list（例： `rel="alternate stylesheet"^c ）として直列化する~OUGHT。 ◎ Finally, the HTML specification gives a special meaning when the “alternate” relation types coincide with other relation types in the same link. Such links ought to be serialised in the Link header field using a single list of relation-types (e.g., rel=”alternate stylesheet”) to preserve this relationship.

A.2. ~Atomにおける~linkの直列化

~Atom `RFC4287$r は、 `~link$を `atom:link^e 要素~内に伝達する ~link直列化法である — そこでは、 `href^a 属性が`~link~target$を指示し， `rel^a 属性が`関係~型$を包含する。 ~linkの`文脈$は、それが出現する所に依存して，`feed locator^en か `entry ID^en になる。一般に， `feed^en ~levelの`~link$は、 `Link$h ~headerとしての伝送~用の明白な候補である。 ◎ Atom [RFC4287] is a link serialisation that conveys links in the atom:link element, with the “href” attribute indicating the link target and the “rel” attribute containing the relation type. The context of the link is either a feed locator or an entry ID, depending on where it appears; generally, feed-level links are obvious candidates for transmission as a Link header field.

`atom:link^e を `Link$h ~headerの中に直列化するときには、 `~link~target$を（もしあれば）~URIに変換することが必要yである。 ◎ When serialising an atom:link into a Link header field, it is necessary to convert link targets (if used) to URIs.

~Atomは、 `拡張~関係~型$を~IRIの用語で定義する。この仕様は、それらの比較を単純~化して~errorを抑制するため，それらを~URIとして定義し直す。 ◎ Atom defines extension relation types in terms of IRIs. This specification redefines them as URIs, to simplify and reduce errors in their comparison.

~Atomでは、 `登録-済み~link関係~型$を，接頭辞 `http://www.iana.org/assignments/relation/^c を利用して絶対~URIとして直列化することが許容される。この接頭辞は、 ~Atom直列化に特有である。 ◎ Atom allows registered link relation types to be serialised as absolute URIs using a prefix, “http://www.iana.org/assignments/relation/”. This prefix is specific to the Atom serialisation.

加えて，`~link関係~型$は、常に文字大小区別で比較される。したがって，~Atom文書~内に直列化されるときには、 `登録-済み~link関係~型$は，その登録-済み形（通例的に小文字）に変換されるベキである。 ◎ Furthermore, 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.

`Link$h ~headerは、複数の関係を単独の~link内に直列化するのを許容する一方で、 `atom:link^e はそうでないことに注意。この事例では、単独の `link-value$p は，いくつかの `atom:link^e 要素に対応付けられてよい。 ◎ Note also that while the Link header field 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.

~HTMLと同じく、 `atom:link^e は，［ `Link$h ~header構文~内には，明示的に~~反映されない属性］をいくつか定義するが、忠実性を保守するためとして，それらも~link拡張として利用できる。 ◎ As with HTML, atom:link defines some attributes that are not explicitly mirrored in the Link header field syntax, but they can also be used as link-extensions to maintain fidelity.

B. `Link^h ~headerの構文解析~用~algo

この付録では、［一連の~headerから `Link$h ~headerを構文解析する／ `Link$h ~header`~field値$, およびその汎用な~~成分を構文解析する］ための，規範的でない~algoを要旨する。 ◎ This appendix outlines a set of non-normative algorithms: for parsing the Link header(s) out of a header set, for parsing a Link header field value, and algorithms for parsing generic parts of the field value.

これらの~algoは、構文を定義している~ABNFより寛容であり，［それら内に具体化される~errorの取扱いは、適理な~approachであるが，要求されるものではない］ことを示唆するかもしれない。そのようなわけで，それらは助言的に限られるので、食い違いがある事例における正しい挙動は，この仕様の本文により定義される。 ◎ These algorithms are more permissive than the ABNF defining the syntax might suggest; the error handling embodied in them is a reasonable approach, but not one that is required. As such they are advisory only, and in cases where there is disagreement, the correct behaviour is defined by the body of this specification.

【記述を簡潔にして精緻化するため、この節においては， Infra 標準に定義される各種用語（例： `~list$や`位置~変数$など）を利用することにする。それに伴い，この節における［ `OWS$p ／ `BWS$p ／ `RWS$p ］は、等価な符号位置の集合（いずれも { U+0020 ~space, U+0009 ~tab } ）として解釈するとする。この節における `DQUOTE$P は、等価な符号位置（ U+0022 ）として解釈するとする。】

B.1. `Link^h ~headerの構文解析-法

~HTTP~message内の `Link$h ~headerを構文解析するときは、 `~header節$内の`結合-$済みな `Link$h `~field値$を `B.2§ に従って構文解析した結果を返す。 ◎ This algorithm can be used to parse the Link header fields that a HTTP header set contains. Given a header_set of (string field_name, string field_value) pairs, assuming ASCII encoding, it returns a list of link objects. • Let field_values be a list containing the members of header_set whose field_name is a case-insensitive match for “link”. • Let links be an empty list. • For each field_value in field_values: •• Let value_links be the result of Parsing A Link Field Value (Appendix B.2) from field_value. •• Append each member of value_links to links. •• Return links.

【この節では、［改訂された~HTTP仕様にて改められた`~field値$の定義］を利用して，［原文による`~field行l値$に基づく記述］を簡素化している。】

B.2. `Link^h ~field値の構文解析-法

この~algoは、 `Link$h ~headerの`~field値$ %~field値を構文解析して， ~link~objの~listを返す： ◎ This algorithm parses zero or more comma-separated link-values from a Link header field. Given a string field_value, assuming ASCII encoding, it returns a list of link objects.

%~link群 ~LET 新たな`~list$ ◎ Let links be an empty list.
%入力 ~SET `~ASCII復号する$( %~field値 ) ◎ ↑
%位置 ~LET %入力の先頭の文字を指している`位置~変数$ （この変数は、この~algoが呼出す下位-手続きからも共有される）
~WHILE［ %位置↗ ~NEQ ε ］： ◎ While field_value has content:
1. %入力内の %位置から `OWS$p からなる`符号位置~並びを収集する$ ◎ Consume any leading OWS.
2. ~IF［ %位置↗ ~NEQ "`<^c" ］ ⇒ ~BREAK【！return links】 ◎ If the first character is not “<”, return links.
3. %位置 ~INCBY 1 ◎ Discard the first character (“<”).
4. %~target文字列 ~LET %入力内の %位置から［ "`>^c" 以外の文字］からなる`符号位置~並びを収集する$ ◎ Consume up to but not including the first “>” character or end of field_value and let the result be target_string.
5. ~IF［ %位置↗ ~EQ ε ］ ⇒ ~BREAK 【！... is not “>”, return links.】 ◎ If the next character is not “>”, return links.
6. %位置 ~INCBY 1 ◎ Discard the leading “>” character.
7. %~link~parameter群 ~LET %入力内の %位置から`~parameter群を構文解析する$ ◎ Let link_parameters be the result of Parsing Parameters (Appendix B.3) from field_value (consuming zero or more characters of it).
8. %~target~URI ~LET `3986/5.2$rfc に従って， %~target文字列を【 `3986/5.1$rfc に従って決定される基底~URIに】相対的に解決した結果 — ただし、 `内容$内に運ばれた基底~URIは`利用しない^emことに注意。 ◎ Let target_uri be the result of relatively resolving (as per [RFC3986], Section 5.2) target_string. Note that any base URI carried in the payload body is NOT used.
9. 【この段は、`~link関係~型$を抽出する】：
  1. %rel ~LET %~link~parameter群[ "`rel^c" ]
  2. %関係~型~文字列 ~LET %rel に応じて ⇒＃ ε ならば空~文字列／ ~ELSE_ %rel[ 0 ]
  3. %関係~型~文字列 ~LET %関係~型~文字列を `RWS$p で分割した結果の~list
    
    【 %関係~型~文字列が `RWS$p しか包含していない場合に，結果が 1 個の空~文字列のみからなるのか空になるのかは、原文からは判別できない。後者の場合、 ~CONTINUE するのと同じ結果になる。】
  ◎ Let relations_string be the second item of the first tuple of link_parameters whose first item matches the string “rel” or the empty string (“”) if it is not present. ◎ Split relations_string on RWS (removing it in the process) into a list of string relation_types.
10. 【この段は、`~link文脈$を抽出する】：
  1. %文脈~URI文字列 ~LET ~NULL
  2. %anchor ~LET %~link~parameter群[ "`anchor^c" ]
  3. ~IF［ %anchor ~NEQ ε ］ ⇒ %文脈~URI文字列 ~SET %anchor[ 0 ]
  4. ~ELSE：
    1. %~URL ~LET `Link$h ~headerを運んでいる`表現$の~URL （ `HTTP$r `内容の識別-法＠~HTTPinfra#identifying.content§ ）【！`7231/3.1.4.1$rfc】
    2. ~IF［ %~URL は匿名でない【 `3.2§ を見よ】］ ⇒ %文脈~URI文字列 ~SET ~URIとして直列化された %~URL
  5. %文脈~URI ~LET ~NULL
  6. ~IF［ %文脈~URI文字列 ~NEQ ~NULL ］ ⇒ %文脈~URI ~SET `3986/5.2$rfc に従って， %文脈~URI文字列を【 `3986/5.1$rfc に従って決定される基底~URIに】相対的に解決した結果 — ただし、 `内容$内に運ばれた基底~URIは `利用しない^emことに注意。
  ◎ Let context_string be the second item of the first tuple of link_parameters whose first item matches the string “anchor”.＼ If it is not present, context_string is the URL of the representation carrying the Link header [RFC7231], Section 3.1.4.1, serialised as a URI.＼ Where the URL is anonymous, context_string is null. ◎ Let context_uri be the result of relatively resolving (as per [RFC3986], Section 5.2) context_string, unless context_string is null, in which case context is null. Note that any base URI carried in the payload body is NOT used.
11. %~link~parameter群[ "`rel^c" ] ~SET ε ◎ ↓
12. %~link~parameter群[ "`anchor^c" ] ~SET ε ◎ ↓
13. « "`media^c" , "`title^c" , "`title*^c", "`type^c" » を成す ~EACH( %~parameter名 ) に対し ⇒ ~IF［ %~link~parameter群[ %~parameter名 ] ~NEQ ε ］ ⇒ %~link~parameter群[ %~parameter名 ] から最初の~item以外を`除去する$ ◎ ↓Let target_attributes be an empty list. ◎ For each tuple (param_name, param_value) of link_parameters: • If param_name matches “rel” or “anchor”, skip this tuple. • If param_name matches “media”, “title”, “title*” or “type” and target_attributes already contains a tuple whose first element matches the value of param_name, skip this tuple. • Append (param_name, param_value) to target_attributes.
14. %~link~parameter群を成す ~EACH( %~parameter名 → %~parameter値 ) に対し：
  1. ~IF［ %~parameter名の最後の文字 ~NEQ "`*^c" ］ ⇒ ~CONTINUE
  2. %~link~parameter群[ %~parameter名 ] ~SET ε
  3. %基底~parameter名 ~LET %~parameter名から最後の文字を除去した結果
  4. ~IF［実装は、何らかの理由で［ %基底~parameter名を国際-化した形として命名される~parameter ］を~supportしない（当の~parameterの仕様により禁制されているものも含むが，それらに制限されない）］ ⇒ ~CONTINUE
  5. %~link~parameter群[ %基底~parameter名 ] ~SET %~parameter値
  【！ Errata 5878: link_parameters → target_attributes】 ◎ Let star_param_names be the set of param_names in the (param_name, param_value) tuples of link_parameters where the last character of param_name is an asterisk (“*”). ◎ For each star_param_name in star_param_names: • Let base_param_name be star_param_name with the last character removed. • If the implementation does not choose to support an internationalised form of a parameter named base_param_name for any reason (including, but not limited to, it being prohibited by the parameter’s specification), remove all tuples from link_parameters whose first member is star_param_name, and skip to the next star_param_name. • Remove all tuples from link_parameters whose first member is base_param_name. • Change the first member of all tuples in link_parameters whose first member is star_param_name to base_param_name.
15. %~target属性~群 ~LET 新たな`~list$ ◎ ↑
16. %~link~parameter群を成す ~EACH( %~parameter名 → %~parameter値 ) に対し ⇒ %~parameter値を成す ~EACH( %~item ) に対し ⇒ %~target属性~群に ~tuple ( %~parameter名, %~item ) を`付加する$ ◎ ↑↓
17. %関係~型~群を成す ~EACH( %関係~型 ) に対し： ◎ For each relation_type in relation_types:
  1. %関係~型 ~SET `~ASCII小文字~化する$( %関係~型 ) ◎ Case-normalise relation_type to lowercase.
  2. %~link群に次のようにされた~link~objを`付加する$ ⇒＃ `~target$ ~SET %~target~URI , `関係~型$ ~SET %関係~型 , `文脈$ ~SET %文脈~URI, `~target属性~群$ ~SET %~target属性~群 ◎ Append a link object to links with the target target_uri, relation type of relation_type, context of context_uri, and target attributes target_attributes.
~RET %~link群 ◎ Return links.

B.3. ~parameter群の構文解析-法

この~algoは、所与の`~ASCII文字列$ %入力内の %位置から~parameter群を構文解析する： ◎ This algorithm parses the parameters from a header field value. Given input, an ASCII string, it returns a list of (string parameter_name, string parameter_value) tuples that it contains. input is modified to remove the parsed parameters.

%~parameter群 ~LET 新たな`有順序~map$ 【~logicを単純~化するため、この訳では，~listに代えて~mapを利用する。】 ◎ Let parameters be an empty list.
~WHILE［ %位置↗ ~NEQ ε ］： ◎ While input has content:
1. %入力内の %位置から `OWS$p からなる`符号位置~並びを収集する$ ◎ Consume any leading OWS.
2. ~IF［ %位置↗ ~NEQ "`;^c" ］ ⇒ ~BREAK ◎ If the first character is not “;”, return parameters.
3. %位置 ~INCBY 1 ◎ Discard the leading “;” character.
4. %入力内の %位置から `OWS$p からなる`符号位置~並びを収集する$ ◎ Consume any leading OWS.
5. %~parameter名 ~LET %入力内の %位置から［ `BWS$p, "`=^c", "`;^c", "`,^c" ］以外の`符号位置~並びを収集する$ ◎ Consume up to but not including the first BWS, “=”, “;”, “,” character or end of input and let the result be parameter_name.
6. %入力内の %位置から `BWS$p からなる`符号位置~並びを収集する$ ◎ Consume any leading BWS.
7. %~parameter値 ~LET 空~文字列 ◎ ↓
8. ~IF［ %位置↗ ~EQ "`=^c" ］： ◎ If the next character is “=”:
  1. %位置 ~INCBY 1 ◎ Discard the leading “=” character.
  2. %入力内の %位置から `BWS$p からなる`符号位置~並びを収集する$ ◎ Consume any leading BWS.
  3. ~IF［ %位置↗ ~EQ `DQUOTE$P ］ ⇒ %~parameter値 ~SET %入力内の %位置から`引用符~付き文字列を構文解析する$ ◎ If the next character is DQUOTE, let parameter_value be the result of Parsing a Quoted String (Appendix B.4) from input (consuming zero or more characters of it).
  4. ~ELSE ⇒ %~parameter値 ~SET %入力内の %位置から { "`;^c", "`,^c" } 以外の`符号位置~並びを収集する$ ◎ Else, consume the contents up to but not including the first “;” or “,” character, or up to the end of input, and let the results be parameter_value.
  5. ~IF［ %~parameter名の最後の文字 ~EQ "`*^c" ］ ⇒ `RFC8187$r に則って %~parameter値を復号する【`3.4.2§ を見よ】 — 回復-不能な~errorに遭遇したときは、 %入力の処理を継続する ◎ If the last character of parameter_name is an asterisk (“*”), decode parameter_value according to [RFC8187]. Continue processing input if an unrecoverable error is encountered.
9. %~parameter名 ~SET `~ASCII小文字~化する$( %~parameter名 ) ◎ ↑Else: • Let parameter_value be an empty string. ◎ Case-normalise parameter_name to lowercase.
10. ~IF［ %~parameter群[ %~parameter名 ] ~EQ ε ］ ⇒ %~parameter群[ %~parameter名 ] ~SET 新たな`~list$ ◎ ↓
11. %~parameter群[ %~parameter名 ] に %~parameter値を`付加する$ ◎ Append (parameter_name, parameter_value) to parameters.
12. %入力内の %位置から `OWS$p からなる`符号位置~並びを収集する$ ◎ Consume any leading OWS.
13. ~IF［ %位置↗ ~EQ "`,^c" ］ ⇒ ~BREAK ◎ If the next character is “,” or the end of input, stop processing input and return parameters.
~RET %~parameter群 ◎ ↑

B.4. 引用符~付き文字列の構文解析-法

この~algoは、 `HTTP$r `引用符~付き文字列＠~HTTPinfra#quoted.strings§【！`7230/3.2.6$rfc】に従って，引用符~付き文字列を構文解析する — これは、引用符を外した文字列を返す： ◎ This algorithm parses a quoted string, as per [RFC7230], Section 3.2.6. Given input, an ASCII string, it returns an unquoted string. input is modified to remove the parsed string.

%出力 ~LET 空~文字列 ◎ Let output be an empty string.
~IF［ %位置↗ ~NEQ `DQUOTE$P ］ ⇒ ~RET %出力 ◎ If the first character of input is not DQUOTE, return output.
%位置 ~INCBY 1 ◎ Discard the first character.
~WHILE 無条件：
1. ~IF［ %位置↗ ~EQ `DQUOTE$P ］ ⇒＃ %位置 ~INCBY 1； ~BREAK【！return output】
2. ~IF［ %位置↗ ~EQ "`\^c" ］ ⇒ %位置 ~INCBY 1
3. ~IF［ %位置↗ ~EQ ε ］ ⇒ ~BREAK【！return output】
4. %出力に %位置↗ を付加する
5. %位置 ~INCBY 1
◎ While input has content: • If the first character is a backslash (“\”): •• Discard the first character. •• If there is no more input, return output. •• Else, consume the first character and append it to output. • Else, if the first character is DQUOTE, discard it and return output. • Else, consume the first character and append it to output.
~RET %出力 ◎ Return output.

C. RFC 5988 からの変更点

この仕様は、次の点で，その前身である RFC 5988 から相違する： ◎ This specification has the following differences from its predecessor, RFC 5988:

初期~関係~型~登録は、除去された — それらはすでに RFC 5988 により登録-済みなので。 ◎ The initial relation type registrations were removed, since they’ve already been registered by RFC 5988.
序論（ `1§ ）は短縮された。 ◎ The introduction has been shortened.
“`Link Relation Application Data^en” ~registryは除去された。 ◎ The “Link Relation Application Data” registry has been removed.
正誤表を組入れた。 ◎ Incorporated errata.
参照を更新した。 ◎ Updated references.
~linkの個数について明確化された。 ◎ Link cardinality was clarified.
~~以前の用語［ “~target~IRI” ／ “文脈~IRI” ］は［ “`~link~target$” ／ “`~link文脈$” ］に変更された。 ◎ Terminology was changed from “target IRI” and “context IRI” to “link target” and “link context”, respectively.
`登録-済み関係~型$に~URIをアテガうのは、その直列化法に特有とした。 ◎ Made assigning a URI to registered relation types serialisation specific.
`Link$h ~headerは意味論的に［ ~HTML／~Atom ］~linkに等価であるとする言明は、 ~~誤解を呼ぶので除去した。 ◎ Removed misleading statement that the Link header field is semantically equivalent to HTML and Atom links.
“~link直列化” ／ “~link応用” を，もっと注意深く定義して利用するようにした。 ◎ More carefully defined and used “link serialisations” and “link applications.”
`~target属性$の個数について明確化した（汎用に, および `type^c 用に）。 ◎ Clarified the cardinality of target attributes (generically and for “type”).
`Link$h ~header用の既定の`~link文脈$を，表現の同一性に依存するように正した（ `HTTP$r に従って）。 ◎ Corrected the default link context for the Link header field, to be dependent upon the identity of the representation (as per RFC 7231).
`Link$h ~header用に示唆される構文解析~algoを定義した。 ◎ Defined a suggested parsing algorithm for the Link header.
`~target属性$の値~空間と，それらの定義を指定した。 ◎ The value space of target attributes and their definition has been specified.
~ABNFは、 `HTTP$r に互換になるように更新された。特に空白は、今や明示的にされた。 ◎ The ABNF has been updated to be compatible with [RFC7230]. In particular, whitespace is now explicit.
`Link$h ~header上の一部の~parameterは、今や`~token形$として出現できる。 ◎ Some parameters on the HTTP header field can now appear as a token.
`Link$h ~header上の~parameterは、今や値なしになれる。 ◎ Parameters on the HTTP header can now be valueless.
`引用符d形$の取扱いは、今や `HTTP$r により定義される。 ◎ Handling of quoted strings is now defined by [RFC7230].
`type^c ~parameterは、今や `quoted-string$p にする必要がある（`~token形$は `/^c を許容しないので）。 ◎ The type header field parameter now needs to be quoted (as token does not allow “/”).

Web リンク法

このメモの位置付け

著作権の告知