--- /dev/null
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
+ "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
+<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
+<head profile="http://dublincore.org/documents/2008/08/04/dc-html/">
+ <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
+ <meta name="robots" content="index,follow" />
+ <meta name="creator" content="rfcmarkup version 1.129d on tools.ietf.org" />
+ <link rel="schema.DC" href="http://purl.org/dc/elements/1.1/" />
+<meta name="DC.Relation.Replaces" content="rfc5988" />
+<meta name="DC.Identifier" content="urn:ietf:rfc:8288" />
+<meta name="DC.Date.Issued" content="October, 2017" />
+<meta name="DC.Creator" content="Mark Nottingham <mnot@mnot.net>" />
+<meta name="DC.Description.Abstract" content="This specification defines a model for the relationships between
+resources on the Web ("links") and the type of those relationships
+("link relation types"). It also defines the serialisation of such
+links in HTTP headers with the Link header field." />
+<meta name="DC.Title" content="Web Linking" />
+
+ <link rel="icon" href="/images/rfc.png" type="image/png" />
+ <link rel="shortcut icon" href="/images/rfc.png" type="image/png" />
+ <title>RFC 8288 - Web Linking</title>
+
+
+ <style type="text/css">
+ @media only screen
+ and (min-width: 992px)
+ and (max-width: 1199px) {
+ body { font-size: 14pt; }
+ div.content { width: 96ex; margin: 0 auto; }
+ }
+ @media only screen
+ and (min-width: 768px)
+ and (max-width: 991px) {
+ body { font-size: 14pt; }
+ div.content { width: 96ex; margin: 0 auto; }
+ }
+ @media only screen
+ and (min-width: 480px)
+ and (max-width: 767px) {
+ body { font-size: 11pt; }
+ div.content { width: 96ex; margin: 0 auto; }
+ }
+ @media only screen
+ and (max-width: 479px) {
+ body { font-size: 8pt; }
+ div.content { width: 96ex; margin: 0 auto; }
+ }
+ @media only screen
+ and (min-device-width : 375px)
+ and (max-device-width : 667px) {
+ body { font-size: 9.5pt; }
+ div.content { width: 96ex; margin: 0; }
+ }
+ @media only screen
+ and (min-device-width: 1200px) {
+ body { font-size: 10pt; margin: 0 4em; }
+ div.content { width: 96ex; margin: 0; }
+ }
+ h1, h2, h3, h4, h5, h6, .h1, .h2, .h3, .h4, .h5, .h6 {
+ font-weight: bold;
+ /* line-height: 0pt; */
+ display: inline;
+ white-space: pre;
+ font-family: monospace;
+ font-size: 1em;
+ font-weight: bold;
+ }
+ pre {
+ font-size: 1em;
+ margin-top: 0px;
+ margin-bottom: 0px;
+ }
+ .pre {
+ white-space: pre;
+ font-family: monospace;
+ }
+ .header{
+ font-weight: bold;
+ }
+ .newpage {
+ page-break-before: always;
+ }
+ .invisible {
+ text-decoration: none;
+ color: white;
+ }
+ a.selflink {
+ color: black;
+ text-decoration: none;
+ }
+ @media print {
+ body {
+ font-family: monospace;
+ font-size: 10.5pt;
+ }
+ h1, h2, h3, h4, h5, h6 {
+ font-size: 1em;
+ }
+
+ a:link, a:visited {
+ color: inherit;
+ text-decoration: none;
+ }
+ .noprint {
+ display: none;
+ }
+ }
+ @media screen {
+ .grey, .grey a:link, .grey a:visited {
+ color: #777;
+ }
+ .docinfo {
+ background-color: #EEE;
+ }
+ .top {
+ border-top: 7px solid #EEE;
+ }
+ .pad {
+ padding-top: 7px;
+ line-height: 24px;
+ padding-bottom: 4px;
+ }
+ .bgwhite { background-color: white; }
+ .bgred { background-color: #F44; }
+ .bggrey { background-color: #666; }
+ .bgbrown { background-color: #840; }
+ .bgorange { background-color: #FA0; }
+ .bgyellow { background-color: #EE0; }
+ .bgmagenta{ background-color: #F4F; }
+ .bgblue { background-color: #66F; }
+ .bgcyan { background-color: #4DD; }
+ .bggreen { background-color: #4F4; }
+
+ .legend { font-size: 90%; }
+ .cplate { font-size: 70%; border: solid grey 1px; }
+ }
+ </style>
+ <!--[if IE]>
+ <style>
+ body {
+ font-size: 13px;
+ margin: 10px 10px;
+ }
+ </style>
+ <![endif]-->
+
+ <script type="text/javascript"><!--
+ function addHeaderTags() {
+ var spans = document.getElementsByTagName("span");
+ for (var i=0; i < spans.length; i++) {
+ var elem = spans[i];
+ if (elem) {
+ var level = elem.getAttribute("class");
+ if (level == "h1" || level == "h2" || level == "h3" || level == "h4" || level == "h5" || level == "h6") {
+ elem.innerHTML = "<"+level+">"+elem.innerHTML+"</"+level+">";
+ }
+ }
+ }
+ }
+ var legend_html = "Colour legend:<br /> <table> <tr><td>Unknown:</td> <td><span class='cplate bgwhite'> </span></td></tr> <tr><td>Draft:</td> <td><span class='cplate bgred'> </span></td></tr> <tr><td>Informational:</td> <td><span class='cplate bgorange'> </span></td></tr> <tr><td>Experimental:</td> <td><span class='cplate bgyellow'> </span></td></tr> <tr><td>Best Common Practice:</td> <td><span class='cplate bgmagenta'> </span></td></tr> <tr><td>Proposed Standard:</td> <td><span class='cplate bgblue'> </span></td></tr> <tr><td>Draft Standard (old designation):</td> <td><span class='cplate bgcyan'> </span></td></tr> <tr><td>Internet Standard:</td> <td><span class='cplate bggreen'> </span></td></tr> <tr><td>Historic:</td> <td><span class='cplate bggrey'> </span></td></tr> <tr><td>Obsolete:</td> <td><span class='cplate bgbrown'> </span></td></tr> </table>";
+ function showElem(id) {
+ var elem = document.getElementById(id);
+ elem.innerHTML = eval(id+"_html");
+ elem.style.visibility='visible';
+ }
+ function hideElem(id) {
+ var elem = document.getElementById(id);
+ elem.style.visibility='hidden';
+ elem.innerHTML = "";
+ }
+ // -->
+ </script>
+</head>
+<body onload="addHeaderTags()">
+ <div class="content">
+ <div style="height: 13px;">
+ <div onmouseover="this.style.cursor='pointer';"
+ onclick="showElem('legend');"
+ onmouseout="hideElem('legend')"
+ style="height: 6px; position: absolute;"
+ class="pre noprint docinfo bgblue"
+ title="Click for colour legend." > </div>
+ <div id="legend"
+ class="docinfo noprint pre legend"
+ style="position:absolute; top: 4px; left: 4ex; visibility:hidden; background-color: white; padding: 4px 9px 5px 7px; border: solid #345 1px; "
+ onmouseover="showElem('legend');"
+ onmouseout="hideElem('legend');">
+ </div>
+ </div>
+<span class="pre noprint docinfo top">[<a href="../html/" title="Document search and retrieval page">Docs</a>] [<a href="/rfc/rfc8288.txt" title="Plaintext version of this document">txt</a>|<a href="/pdf/rfc8288" title="PDF version of this document">pdf</a>] [<a href="./draft-nottingham-rfc5988bis" title="draft-nottingham-rfc5988bis">draft-nottingha...</a>] [<a href='https://datatracker.ietf.org/doc/rfc8288' title='IESG Datatracker information for this document'>Tracker</a>] [<a href="/rfcdiff?difftype=--hwdiff&url2=rfc8288" title="Inline diff (wdiff)">Diff1</a>] [<a href="/rfcdiff?url2=rfc8288" title="Side-by-side diff">Diff2</a>] [<a href="https://www.rfc-editor.org/errata_search.php?rfc=8288">Errata</a>]</span><br />
+<span class="pre noprint docinfo"> </span><br />
+<span class="pre noprint docinfo"> PROPOSED STANDARD</span><br />
+<span class="pre noprint docinfo"> <span style='color: #C00;'>Errata Exist</span></span><br />
+<pre>
+Internet Engineering Task Force (IETF) M. Nottingham
+Request for Comments: 8288 October 2017
+Obsoletes: <a href="./rfc5988">5988</a>
+Category: Standards Track
+ISSN: 2070-1721
+
+
+ <span class="h1">Web Linking</span>
+
+Abstract
+
+ This specification defines a model for the relationships between
+ resources on the Web ("links") and the type of those relationships
+ ("link relation types").
+
+ It also defines the serialisation of such links in HTTP headers with
+ the Link header field.
+
+Status of This Memo
+
+ This is an Internet Standards Track document.
+
+ This document is a product of the Internet Engineering Task Force
+ (IETF). It represents the consensus of the IETF community. It has
+ received public review and has been approved for publication by the
+ Internet Engineering Steering Group (IESG). Further information on
+ Internet Standards is available in <a href="./rfc7841#section-2">Section 2 of RFC 7841</a>.
+
+ Information about the current status of this document, any errata,
+ and how to provide feedback on it may be obtained at
+ <a href="https://www.rfc-editor.org/info/rfc8288">https://www.rfc-editor.org/info/rfc8288</a>.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+<span class="grey">Nottingham Standards Track [Page 1]</span></pre>
+<hr class='noprint' style='width: 96ex;' align='left'/><!--NewPage--><pre class='newpage'><a name="page-2" id="page-2" href="#page-2" class="invisible"> </a>
+<span class="grey"><a href="./rfc8288">RFC 8288</a> Web Linking October 2017</span>
+
+
+Copyright Notice
+
+ Copyright (c) 2017 IETF Trust and the persons identified as the
+ document authors. All rights reserved.
+
+ This document is subject to <a href="./bcp78">BCP 78</a> and the IETF Trust's Legal
+ Provisions Relating to IETF Documents
+ (<a href="https://trustee.ietf.org/license-info">https://trustee.ietf.org/license-info</a>) 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.
+
+ 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+<span class="grey">Nottingham Standards Track [Page 2]</span></pre>
+<hr class='noprint' style='width: 96ex;' align='left'/><!--NewPage--><pre class='newpage'><a name="page-3" id="page-3" href="#page-3" class="invisible"> </a>
+<span class="grey"><a href="./rfc8288">RFC 8288</a> Web Linking October 2017</span>
+
+
+Table of Contents
+
+ <a href="#section-1">1</a>. Introduction . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-4">4</a>
+ <a href="#section-1.1">1.1</a>. Notational Conventions . . . . . . . . . . . . . . . . . <a href="#page-4">4</a>
+ <a href="#section-1.2">1.2</a>. Conformance and Error Handling . . . . . . . . . . . . . <a href="#page-4">4</a>
+ <a href="#section-2">2</a>. Links . . . . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-6">6</a>
+ <a href="#section-2.1">2.1</a>. Link Relation Types . . . . . . . . . . . . . . . . . . . <a href="#page-6">6</a>
+ <a href="#section-2.1.1">2.1.1</a>. Registered Relation Types . . . . . . . . . . . . . . <a href="#page-6">6</a>
+ <a href="#section-2.1.2">2.1.2</a>. Extension Relation Types . . . . . . . . . . . . . . <a href="#page-8">8</a>
+ <a href="#section-2.2">2.2</a>. Target Attributes . . . . . . . . . . . . . . . . . . . . <a href="#page-9">9</a>
+ <a href="#section-3">3</a>. Link Serialisation in HTTP Headers . . . . . . . . . . . . . <a href="#page-9">9</a>
+ <a href="#section-3.1">3.1</a>. Link Target . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-10">10</a>
+ <a href="#section-3.2">3.2</a>. Link Context . . . . . . . . . . . . . . . . . . . . . . <a href="#page-10">10</a>
+ <a href="#section-3.3">3.3</a>. Relation Type . . . . . . . . . . . . . . . . . . . . . . <a href="#page-11">11</a>
+ <a href="#section-3.4">3.4</a>. Target Attributes . . . . . . . . . . . . . . . . . . . . <a href="#page-11">11</a>
+ <a href="#section-3.4.1">3.4.1</a>. Serialisation-Defined Attributes . . . . . . . . . . <a href="#page-11">11</a>
+ <a href="#section-3.4.2">3.4.2</a>. Extension Attributes . . . . . . . . . . . . . . . . <a href="#page-13">13</a>
+ <a href="#section-3.5">3.5</a>. Link Header Field Examples . . . . . . . . . . . . . . . <a href="#page-13">13</a>
+ <a href="#section-4">4</a>. IANA Considerations . . . . . . . . . . . . . . . . . . . . . <a href="#page-14">14</a>
+ <a href="#section-4.1">4.1</a>. Link HTTP Header Field Registration . . . . . . . . . . . <a href="#page-14">14</a>
+ <a href="#section-4.2">4.2</a>. Link Relation Type Registry . . . . . . . . . . . . . . . <a href="#page-14">14</a>
+ <a href="#section-4.3">4.3</a>. Link Relation Application Data Registry . . . . . . . . . <a href="#page-15">15</a>
+ <a href="#section-5">5</a>. Security Considerations . . . . . . . . . . . . . . . . . . . <a href="#page-15">15</a>
+ <a href="#section-6">6</a>. Internationalisation Considerations . . . . . . . . . . . . . <a href="#page-16">16</a>
+ <a href="#section-7">7</a>. References . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-16">16</a>
+ <a href="#section-7.1">7.1</a>. Normative References . . . . . . . . . . . . . . . . . . <a href="#page-16">16</a>
+ <a href="#section-7.2">7.2</a>. Informative References . . . . . . . . . . . . . . . . . <a href="#page-17">17</a>
+ <a href="#appendix-A">Appendix A</a>. Notes on Other Link Serialisations . . . . . . . . . <a href="#page-19">19</a>
+ <a href="#appendix-A.1">A.1</a>. Link Serialisation in HTML . . . . . . . . . . . . . . . <a href="#page-19">19</a>
+ <a href="#appendix-A.2">A.2</a>. Link Serialisation in Atom . . . . . . . . . . . . . . . <a href="#page-19">19</a>
+ <a href="#appendix-B">Appendix B</a>. Algorithms for Parsing Link Header Fields . . . . . <a href="#page-20">20</a>
+ <a href="#appendix-B.1">B.1</a>. Parsing a Header Set for Links . . . . . . . . . . . . . <a href="#page-20">20</a>
+ <a href="#appendix-B.2">B.2</a>. Parsing a Link Field Value . . . . . . . . . . . . . . . <a href="#page-21">21</a>
+ <a href="#appendix-B.3">B.3</a>. Parsing Parameters . . . . . . . . . . . . . . . . . . . <a href="#page-22">22</a>
+ <a href="#appendix-B.4">B.4</a>. Parsing a Quoted String . . . . . . . . . . . . . . . . . <a href="#page-23">23</a>
+ <a href="#appendix-C">Appendix C</a>. Changes from <a href="./rfc5988">RFC 5988</a> . . . . . . . . . . . . . . . <a href="#page-24">24</a>
+ Author's Address . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-24">24</a>
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+<span class="grey">Nottingham Standards Track [Page 3]</span></pre>
+<hr class='noprint' style='width: 96ex;' align='left'/><!--NewPage--><pre class='newpage'><a name="page-4" id="page-4" href="#page-4" class="invisible"> </a>
+<span class="grey"><a href="./rfc8288">RFC 8288</a> Web Linking October 2017</span>
+
+
+<span class="h2"><a class="selflink" name="section-1" href="#section-1">1</a>. Introduction</span>
+
+ This specification defines a model for the relationships between
+ resources on the Web ("links") and the type of those relationships
+ ("link relation types").
+
+ HTML [<a href="#ref-W3C.REC-html5-20141028" title=""HTML5"">W3C.REC-html5-20141028</a>] and Atom [<a href="./rfc4287" title=""The Atom Syndication Format"">RFC4287</a>] both have well-
+ defined concepts of linking; <a href="#section-2">Section 2</a> generalises this into a
+ framework that encompasses linking in these formats and (potentially)
+ elsewhere.
+
+ Furthermore, <a href="#section-3">Section 3</a> defines an HTTP header field for conveying
+ such links.
+
+<span class="h3"><a class="selflink" name="section-1.1" href="#section-1.1">1.1</a>. Notational Conventions</span>
+
+ 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 <a href="./bcp14">BCP</a>
+ <a href="./bcp14">14</a> [<a href="./rfc2119" title=""Key words for use in RFCs to Indicate Requirement Levels"">RFC2119</a>] [<a href="./rfc8174" title=""Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words"">RFC8174</a>] when, and only when, they appear in all
+ capitals, as shown here.
+
+ This document uses the Augmented Backus-Naur Form (ABNF) [<a href="./rfc5234" title=""Augmented BNF for Syntax Specifications: ABNF"">RFC5234</a>]
+ notation of [<a href="./rfc7230" title=""Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing"">RFC7230</a>], 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.
+
+ Additionally, the following rules are included:
+
+ o URI and URI-Reference from [<a href="./rfc3986" title=""Uniform Resource Identifier (URI): Generic Syntax"">RFC3986</a>],
+ o type-name and subtype-name from [<a href="./rfc6838" title=""Media Type Specifications and Registration Procedures"">RFC6838</a>],
+ o media-query-list from [<a href="#ref-W3C.REC-css3-mediaqueries-20120619" title=""Media Queries"">W3C.REC-css3-mediaqueries-20120619</a>], and
+ o Language-Tag from [<a href="./rfc5646" title=""Tags for Identifying Languages"">RFC5646</a>].
+
+<span class="h3"><a class="selflink" name="section-1.2" href="#section-1.2">1.2</a>. Conformance and Error Handling</span>
+
+ The requirements regarding conformance and error handling highlighted
+ in <a href="./rfc7230#section-2.5">[RFC7230], Section 2.5</a> apply to this document.
+
+
+
+
+
+
+
+
+
+
+
+
+<span class="grey">Nottingham Standards Track [Page 4]</span></pre>
+<hr class='noprint' style='width: 96ex;' align='left'/><!--NewPage--><pre class='newpage'><a name="page-5" id="page-5" href="#page-5" class="invisible"> </a>
+<span class="grey"><a href="./rfc8288">RFC 8288</a> Web Linking October 2017</span>
+
+
+<span class="h2"><a class="selflink" name="section-2" href="#section-2">2</a>. Links</span>
+
+ In this specification, a link is a typed connection between two
+ resources and is comprised of:
+
+ o a link context,
+ o a link relation type (<a href="#section-2.1">Section 2.1</a>),
+ o a link target, and
+ o optionally, target attributes (<a href="#section-2.2">Section 2.2</a>).
+
+ 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".
+
+ For example, "https://www.example.com/" has a "canonical" resource at
+ "https://example.com", which has a "type" of "text/html".
+
+ Link contexts and link targets are both Internationalized Resource
+ Identifiers (IRIs) [<a href="./rfc3987" title=""Internationalized Resource Identifiers (IRIs)"">RFC3987</a>]. However, in the common case, the link
+ context will also be a URI [<a href="./rfc3986" title=""Uniform Resource Identifier (URI): Generic Syntax"">RFC3986</a>], because many protocols (such as
+ HTTP) do not support dereferencing IRIs. Likewise, the link target
+ will sometimes be converted to a URI (see <a href="./rfc3987#section-3.1">[RFC3987], Section 3.1</a>) in
+ serialisations that do not support IRIs (such as the Link header
+ field defined in <a href="#section-3">Section 3</a>).
+
+ 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.
+
+ Links are conveyed in link serialisations; they are the "bytes on the
+ wire", and can occur in various forms. For example, Atom [<a href="./rfc4287" title=""The Atom Syndication Format"">RFC4287</a>]
+ and HTML [<a href="#ref-W3C.REC-html5-20141028" title=""HTML5"">W3C.REC-html5-20141028</a>] both defined serialisations of
+ links into their respective formats, and <a href="#section-3">Section 3</a> defines how to
+ serialise links in HTTP header fields.
+
+ 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.
+
+ 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
+
+
+
+<span class="grey">Nottingham Standards Track [Page 5]</span></pre>
+<hr class='noprint' style='width: 96ex;' align='left'/><!--NewPage--><pre class='newpage'><a name="page-6" id="page-6" href="#page-6" class="invisible"> </a>
+<span class="grey"><a href="./rfc8288">RFC 8288</a> Web Linking October 2017</span>
+
+
+ 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.
+
+<span class="h3"><a class="selflink" name="section-2.1" href="#section-2.1">2.1</a>. Link Relation Types</span>
+
+ 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 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).
+
+ Relation types are not to be confused with media types [<a href="./rfc2046" title=""Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types"">RFC2046</a>];
+ 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.
+
+ 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.
+
+ There are two kinds of relation types: registered and extension.
+
+<span class="h4"><a class="selflink" name="section-2.1.1" href="#section-2.1.1">2.1.1</a>. Registered Relation Types</span>
+
+ Well-defined relation types can be registered as tokens for
+ convenience and/or to promote reuse by other applications, using the
+ procedure in <a href="#section-2.1.1.1">Section 2.1.1.1</a>.
+
+ Registered relation type names MUST conform to the reg-rel-type rule
+ (see <a href="#section-3.3">Section 3.3</a>) and MUST be compared character by character in a
+ case-insensitive fashion. 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.
+
+ 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
+
+
+
+<span class="grey">Nottingham Standards Track [Page 6]</span></pre>
+<hr class='noprint' style='width: 96ex;' align='left'/><!--NewPage--><pre class='newpage'><a name="page-7" id="page-7" href="#page-7" class="invisible"> </a>
+<span class="grey"><a href="./rfc8288">RFC 8288</a> Web Linking October 2017</span>
+
+
+ HTTP methods, and request and response media types that are required
+ be supported).
+
+ Historically, registered relation types have been identified with a
+ URI [<a href="./rfc3986" title=""Uniform Resource Identifier (URI): Generic Syntax"">RFC3986</a>] by prefixing their names with an application-defined
+ base URI (e.g., see <a href="#appendix-A.2">Appendix A.2</a>). 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.
+
+<span class="h5"><a class="selflink" name="section-2.1.1.1" href="#section-2.1.1.1">2.1.1.1</a>. Registering Link Relation Types</span>
+
+ The "Link Relations" registry is located at
+ <<a href="https://www.iana.org/assignments/link-relations/">https://www.iana.org/assignments/link-relations/</a>>. Registration
+ requests can be made by following the instructions located there or
+ by sending an email to the <link-relations@ietf.org> mailing list.
+
+ Registration requests consist of at least the following information:
+
+ o *Relation Name*: The name of the relation type
+
+ o *Description*: 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.
+
+ o *Reference*: 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.
+
+ The expert(s) can define additional fields to be collected in the
+ registry.
+
+ General requirements for registered relation types are described in
+ <a href="#section-2.1.1">Section 2.1.1</a>.
+
+ Registrations MUST reference a freely available, stable
+ specification.
+
+ 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.
+
+
+
+
+
+<span class="grey">Nottingham Standards Track [Page 7]</span></pre>
+<hr class='noprint' style='width: 96ex;' align='left'/><!--NewPage--><pre class='newpage'><a name="page-8" id="page-8" href="#page-8" class="invisible"> </a>
+<span class="grey"><a href="./rfc8288">RFC 8288</a> Web Linking October 2017</span>
+
+
+<span class="h5"><a class="selflink" name="section-2.1.1.2" href="#section-2.1.1.2">2.1.1.2</a>. Registration Request Processing</span>
+
+ Relation types are registered using the Specification Required policy
+ (see <a href="./rfc8126#section-4.6">Section 4.6 of [RFC8126]</a>), which implies review and approval by
+ a designated expert.
+
+ 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, not
+ likely to be used on the Internet, or actively harmful to the
+ Internet and/or the Web (not merely aesthetically displeasing or
+ architecturally dubious). As stated in <a href="#section-2.1.1">Section 2.1.1</a>, the expert(s)
+ can withhold registration of names that are too general for the
+ proposed application.
+
+ 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.
+
+ 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.
+
+<span class="h4"><a class="selflink" name="section-2.1.2" href="#section-2.1.2">2.1.2</a>. Extension Relation Types</span>
+
+ Applications that don't wish to register a relation type can use an
+ extension relation type, which is a URI [<a href="./rfc3986" title=""Uniform Resource Identifier (URI): Generic Syntax"">RFC3986</a>] 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.
+
+ 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.
+
+ 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.
+
+ 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.
+
+
+
+
+
+
+<span class="grey">Nottingham Standards Track [Page 8]</span></pre>
+<hr class='noprint' style='width: 96ex;' align='left'/><!--NewPage--><pre class='newpage'><a name="page-9" id="page-9" href="#page-9" class="invisible"> </a>
+<span class="grey"><a href="./rfc8288">RFC 8288</a> Web Linking October 2017</span>
+
+
+<span class="h3"><a class="selflink" name="section-2.2" href="#section-2.2">2.2</a>. Target Attributes</span>
+
+ Target attributes are a list of key/value pairs that describe the
+ link or its target; for example, a media type hint.
+
+ They can be defined both by individual link relation types and by
+ link serialisations.
+
+ 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.
+
+ 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 attribute definitions SHOULD specify:
+
+ o The serialisation of their values into Unicode or a subset
+ thereof, to maximise their chances of portability across link
+ serialisations.
+ o The semantics and error handling of multiple occurrences of the
+ target attribute on a given link.
+
+ This specification does define target attributes for use in the Link
+ HTTP header field in <a href="#section-3.4">Section 3.4</a>.
+
+<span class="h2"><a class="selflink" name="section-3" href="#section-3">3</a>. Link Serialisation in HTTP Headers</span>
+
+ The Link header field provides a means for serialising one or more
+ links into HTTP headers.
+
+ The ABNF for the field value is:
+
+ Link = #link-value
+ link-value = "<" URI-Reference ">" *( OWS ";" OWS link-param )
+ link-param = token BWS [ "=" BWS ( token / quoted-string ) ]
+
+ 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"
+
+
+
+<span class="grey">Nottingham Standards Track [Page 9]</span></pre>
+<hr class='noprint' style='width: 96ex;' align='left'/><!--NewPage--><pre class='newpage'><a name="page-10" id="page-10" href="#page-10" class="invisible"> </a>
+<span class="grey"><a href="./rfc8288">RFC 8288</a> Web Linking October 2017</span>
+
+
+ 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.
+
+ Individual link-params specify their syntax in terms of the value
+ after any necessary unquoting (as per <a href="./rfc7230#section-3.2.6">[RFC7230], Section 3.2.6</a>).
+
+ 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).
+
+<span class="h3"><a class="selflink" name="section-3.1" href="#section-3.1">3.1</a>. Link Target</span>
+
+ Each link-value conveys one target IRI as a URI-Reference (after
+ conversion to one, if necessary; see <a href="./rfc3987#section-3.1">[RFC3987], Section 3.1</a>) inside
+ angle brackets ("<>"). If the URI-Reference is relative, parsers
+ MUST resolve it as per <a href="./rfc3986#section-5">[RFC3986], Section 5</a>. Note that any base IRI
+ appearing in the message's content is not applied.
+
+<span class="h3"><a class="selflink" name="section-3.2" href="#section-3.2">3.2</a>. Link Context</span>
+
+ 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
+ <a href="./rfc7231#section-3.1.4.1">[RFC7231], Section 3.1.4.1</a>, and is serialised as a URI.
+
+ 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 <a href="./rfc3986#section-5">[RFC3986],
+ Section 5</a>. Note that any base URI from the body's content is not
+ applied.
+
+ The ABNF for the "anchor" parameter's value is:
+
+ URI-Reference ; <a href="./rfc3986#section-4.1">Section 4.1 of [RFC3986]</a>
+
+ 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.
+
+ 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.
+
+
+
+<span class="grey">Nottingham Standards Track [Page 10]</span></pre>
+<hr class='noprint' style='width: 96ex;' align='left'/><!--NewPage--><pre class='newpage'><a name="page-11" id="page-11" href="#page-11" class="invisible"> </a>
+<span class="grey"><a href="./rfc8288">RFC 8288</a> Web Linking October 2017</span>
+
+
+<span class="h3"><a class="selflink" name="section-3.3" href="#section-3.3">3.3</a>. Relation Type</span>
+
+ 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.
+
+ 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.
+
+ 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.
+
+ The ABNF for the rel and rev parameters' values is:
+
+ relation-type *( 1*SP relation-type )
+
+ where:
+
+ relation-type = reg-rel-type / ext-rel-type
+ reg-rel-type = LOALPHA *( LOALPHA / DIGIT / "." / "-" )
+ ext-rel-type = URI ; <a href="./rfc3986#section-3">Section 3 of [RFC3986]</a>
+
+ 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).
+
+<span class="h3"><a class="selflink" name="section-3.4" href="#section-3.4">3.4</a>. Target Attributes</span>
+
+ 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 <a href="./rfc7231#section-3.1.1.1">[RFC7231], Section 3.1.1.1</a> for the definition of
+ their syntax).
+
+<span class="h4"><a class="selflink" name="section-3.4.1" href="#section-3.4.1">3.4.1</a>. Serialisation-Defined Attributes</span>
+
+ The "hreflang", "media", "title", "title*", and "type" link-params
+ can be translated to serialisation-defined target attributes for the
+ link.
+
+
+
+
+
+<span class="grey">Nottingham Standards Track [Page 11]</span></pre>
+<hr class='noprint' style='width: 96ex;' align='left'/><!--NewPage--><pre class='newpage'><a name="page-12" id="page-12" href="#page-12" class="invisible"> </a>
+<span class="grey"><a href="./rfc8288">RFC 8288</a> Web Linking October 2017</span>
+
+
+ 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.
+
+ The ABNF for the hreflang parameter's value is:
+
+ Language-Tag
+
+ The "media" attribute, when present, is used to indicate intended
+ destination medium or media for style information (see
+ [<a href="#ref-W3C.REC-html5-20141028" title=""HTML5"">W3C.REC-html5-20141028</a>], 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.
+
+ The ABNF for the media parameter's value is:
+
+ media-query-list
+
+ 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.
+
+ The "title*" link-param can be used to encode this attribute in a
+ different character set and/or contain language information as per
+ [<a href="./rfc8187" title=""Indicating Character Encoding and Language for HTTP Header Field Parameters"">RFC8187</a>]. 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).
+
+ 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.
+
+ 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
+
+
+
+
+
+<span class="grey">Nottingham Standards Track [Page 12]</span></pre>
+<hr class='noprint' style='width: 96ex;' align='left'/><!--NewPage--><pre class='newpage'><a name="page-13" id="page-13" href="#page-13" class="invisible"> </a>
+<span class="grey"><a href="./rfc8288">RFC 8288</a> Web Linking October 2017</span>
+
+
+ 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.
+
+ The ABNF for the type parameter's value is:
+
+ type-name "/" subtype-name ; see <a href="./rfc6838#section-4.2">Section 4.2 of [RFC6838]</a>
+
+<span class="h4"><a class="selflink" name="section-3.4.2" href="#section-3.4.2">3.4.2</a>. Extension Attributes</span>
+
+ Other link-params are link-extensions and are to be considered as
+ target attributes.
+
+ Such target attributes MAY be defined to use the encoding in
+ [<a href="./rfc8187" title=""Indicating Character Encoding and Language for HTTP Header Field Parameters"">RFC8187</a>] (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
+ [<a href="./rfc8187" title=""Indicating Character Encoding and Language for HTTP Header Field Parameters"">RFC8187</a>] decoding) but MAY fall back to the other value if there is
+ an error in decoding it, or if they do not support decoding.
+
+<span class="h3"><a class="selflink" name="section-3.5" href="#section-3.5">3.5</a>. Link Header Field Examples</span>
+
+ 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.
+
+ 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".
+
+ This link:
+
+ Link: </terms>; rel="copyright"; anchor="#foo"
+
+ indicates that the linked copyright terms only apply to the portion
+ of the document indicated by the (media type-specific) fragment
+ identifier "foo".
+
+ The example below shows an instance of the Link header field encoding
+ multiple links and also the use of the encoding from <a href="./rfc8187">RFC 8187</a> to
+ encode both non-ASCII characters and language information.
+
+
+
+<span class="grey">Nottingham Standards Track [Page 13]</span></pre>
+<hr class='noprint' style='width: 96ex;' align='left'/><!--NewPage--><pre class='newpage'><a name="page-14" id="page-14" href="#page-14" class="invisible"> </a>
+<span class="grey"><a href="./rfc8288">RFC 8288</a> Web Linking October 2017</span>
+
+
+ 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, both use the German
+ language ("de"), and the second link contains the Unicode code point
+ U+00E4 ("LATIN SMALL LETTER A WITH DIAERESIS").
+
+ 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"
+
+ Here, the link to "http://example.org/" has the registered relation
+ type "start" and the extension relation type
+ "http://example.net/relation/other".
+
+ 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"
+
+<span class="h2"><a class="selflink" name="section-4" href="#section-4">4</a>. IANA Considerations</span>
+
+<span class="h3"><a class="selflink" name="section-4.1" href="#section-4.1">4.1</a>. Link HTTP Header Field Registration</span>
+
+ This specification updates the "Message Headers" registry entry for
+ "Link" in HTTP [<a href="./rfc3864" title=""Registration Procedures for Message Header Fields"">RFC3864</a>] to refer to this document.
+
+ Header Field Name: Link
+ Protocol: http
+ Status: standard
+ Reference: <a href="./rfc8288">RFC 8288</a>
+
+<span class="h3"><a class="selflink" name="section-4.2" href="#section-4.2">4.2</a>. Link Relation Type Registry</span>
+
+ This specification updates the registration procedures for the "Link
+ Relation Types" registry; see <a href="#section-2.1.1.1">Section 2.1.1.1</a>. Also, all references
+ to <a href="./rfc5988">RFC 5988</a> in that registry have been replaced with references to
+ this document.
+
+
+
+
+<span class="grey">Nottingham Standards Track [Page 14]</span></pre>
+<hr class='noprint' style='width: 96ex;' align='left'/><!--NewPage--><pre class='newpage'><a name="page-15" id="page-15" href="#page-15" class="invisible"> </a>
+<span class="grey"><a href="./rfc8288">RFC 8288</a> Web Linking October 2017</span>
+
+
+ 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.
+
+ Note that the expert(s) is allowed (as per <a href="#section-2.1.1.1">Section 2.1.1.1</a>) to define
+ additional fields to be collected in the registry.
+
+<span class="h3"><a class="selflink" name="section-4.3" href="#section-4.3">4.3</a>. Link Relation Application Data Registry</span>
+
+ Per this specification, IANA has removed the "Link Relation
+ Application Data" registry, as it has not been used, and future use
+ is not anticipated.
+
+<span class="h2"><a class="selflink" name="section-5" href="#section-5">5</a>. Security Considerations</span>
+
+ The content of the Link header field is not secure, private, or
+ integrity-guaranteed. Use of Transport Layer Security (TLS) with
+ HTTP [<a href="./rfc2818" title=""HTTP Over TLS"">RFC2818</a>] is currently the only end-to-end way to provide these
+ properties.
+
+ Link applications ought to consider the attack vectors opened by
+ automatically following, trusting, or otherwise using links gathered
+ from HTTP header fields.
+
+ 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).
+
+ Dereferencing links has a number of risks, depending on the
+ application in use. For example, the Referer header [<a href="./rfc7231" title=""Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content"">RFC7231</a>] can
+ expose information about the application's state (including private
+ information) in its value. Likewise, cookies [<a href="./rfc6265" title=""HTTP State Management Mechanism"">RFC6265</a>] are another
+ mechanism that, if used, can become an attack vector. Applications
+ can mitigate these risks by carefully specifying how such mechanisms
+ should operate.
+
+ The Link header field makes extensive use of IRIs and URIs. See
+ <a href="./rfc3987#section-8">[RFC3987], Section 8</a> for security considerations relating to IRIs.
+ See <a href="./rfc3986#section-7">[RFC3986], Section 7</a> for security considerations relating to
+ URIs. See <a href="./rfc7230#section-9">[RFC7230], Section 9</a> for security considerations relating
+ to HTTP header fields.
+
+
+
+
+
+
+<span class="grey">Nottingham Standards Track [Page 15]</span></pre>
+<hr class='noprint' style='width: 96ex;' align='left'/><!--NewPage--><pre class='newpage'><a name="page-16" id="page-16" href="#page-16" class="invisible"> </a>
+<span class="grey"><a href="./rfc8288">RFC 8288</a> Web Linking October 2017</span>
+
+
+<span class="h2"><a class="selflink" name="section-6" href="#section-6">6</a>. Internationalisation Considerations</span>
+
+ 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.
+
+ Similarly, the anchor parameter of the Link header field does not
+ support IRIs; therefore, IRIs must be converted to URIs before
+ inclusion there.
+
+ 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.
+
+ Note that registered Relation Names are required to be lowercase
+ ASCII letters.
+
+<span class="h2"><a class="selflink" name="section-7" href="#section-7">7</a>. References</span>
+
+<span class="h3"><a class="selflink" name="section-7.1" href="#section-7.1">7.1</a>. Normative References</span>
+
+ [<a name="ref-RFC2119" id="ref-RFC2119">RFC2119</a>] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", <a href="./bcp14">BCP 14</a>, <a href="./rfc2119">RFC 2119</a>,
+ DOI 10.17487/RFC2119, March 1997,
+ <<a href="https://www.rfc-editor.org/info/rfc2119">https://www.rfc-editor.org/info/rfc2119</a>>.
+
+ [<a name="ref-RFC3864" id="ref-RFC3864">RFC3864</a>] Klyne, G., Nottingham, M., and J. Mogul, "Registration
+ Procedures for Message Header Fields", <a href="./bcp90">BCP 90</a>, <a href="./rfc3864">RFC 3864</a>,
+ DOI 10.17487/RFC3864, September 2004,
+ <<a href="https://www.rfc-editor.org/info/rfc3864">https://www.rfc-editor.org/info/rfc3864</a>>.
+
+ [<a name="ref-RFC3986" id="ref-RFC3986">RFC3986</a>] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
+ Resource Identifier (URI): Generic Syntax", STD 66,
+ <a href="./rfc3986">RFC 3986</a>, DOI 10.17487/RFC3986, January 2005,
+ <<a href="https://www.rfc-editor.org/info/rfc3986">https://www.rfc-editor.org/info/rfc3986</a>>.
+
+ [<a name="ref-RFC3987" id="ref-RFC3987">RFC3987</a>] Duerst, M. and M. Suignard, "Internationalized Resource
+ Identifiers (IRIs)", <a href="./rfc3987">RFC 3987</a>, DOI 10.17487/RFC3987,
+ January 2005, <<a href="https://www.rfc-editor.org/info/rfc3987">https://www.rfc-editor.org/info/rfc3987</a>>.
+
+ [<a name="ref-RFC5234" id="ref-RFC5234">RFC5234</a>] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
+ Specifications: ABNF", STD 68, <a href="./rfc5234">RFC 5234</a>,
+ DOI 10.17487/RFC5234, January 2008,
+ <<a href="https://www.rfc-editor.org/info/rfc5234">https://www.rfc-editor.org/info/rfc5234</a>>.
+
+ [<a name="ref-RFC5646" id="ref-RFC5646">RFC5646</a>] Phillips, A., Ed. and M. Davis, Ed., "Tags for Identifying
+ Languages", <a href="./bcp47">BCP 47</a>, <a href="./rfc5646">RFC 5646</a>, DOI 10.17487/RFC5646,
+ September 2009, <<a href="https://www.rfc-editor.org/info/rfc5646">https://www.rfc-editor.org/info/rfc5646</a>>.
+
+
+
+<span class="grey">Nottingham Standards Track [Page 16]</span></pre>
+<hr class='noprint' style='width: 96ex;' align='left'/><!--NewPage--><pre class='newpage'><a name="page-17" id="page-17" href="#page-17" class="invisible"> </a>
+<span class="grey"><a href="./rfc8288">RFC 8288</a> Web Linking October 2017</span>
+
+
+ [<a name="ref-RFC6838" id="ref-RFC6838">RFC6838</a>] Freed, N., Klensin, J., and T. Hansen, "Media Type
+ Specifications and Registration Procedures", <a href="./bcp13">BCP 13</a>,
+ <a href="./rfc6838">RFC 6838</a>, DOI 10.17487/RFC6838, January 2013,
+ <<a href="https://www.rfc-editor.org/info/rfc6838">https://www.rfc-editor.org/info/rfc6838</a>>.
+
+ [<a name="ref-RFC7230" id="ref-RFC7230">RFC7230</a>] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
+ Protocol (HTTP/1.1): Message Syntax and Routing",
+ <a href="./rfc7230">RFC 7230</a>, DOI 10.17487/RFC7230, June 2014,
+ <<a href="https://www.rfc-editor.org/info/rfc7230">https://www.rfc-editor.org/info/rfc7230</a>>.
+
+ [<a name="ref-RFC7231" id="ref-RFC7231">RFC7231</a>] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
+ Protocol (HTTP/1.1): Semantics and Content", <a href="./rfc7231">RFC 7231</a>,
+ DOI 10.17487/RFC7231, June 2014,
+ <<a href="https://www.rfc-editor.org/info/rfc7231">https://www.rfc-editor.org/info/rfc7231</a>>.
+
+ [<a name="ref-RFC8126" id="ref-RFC8126">RFC8126</a>] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
+ Writing an IANA Considerations Section in RFCs", <a href="./bcp26">BCP 26</a>,
+ <a href="./rfc8126">RFC 8126</a>, DOI 10.17487/RFC8126, June 2017,
+ <<a href="https://www.rfc-editor.org/info/rfc8126">https://www.rfc-editor.org/info/rfc8126</a>>.
+
+ [<a name="ref-RFC8174" id="ref-RFC8174">RFC8174</a>] Leiba, B., "Ambiguity of Uppercase vs Lowercase in <a href="./rfc2119">RFC</a>
+ <a href="./rfc2119">2119</a> Key Words", <a href="./bcp14">BCP 14</a>, <a href="./rfc8174">RFC 8174</a>, DOI 10.17487/RFC8174,
+ May 2017, <<a href="https://www.rfc-editor.org/info/rfc8174">https://www.rfc-editor.org/info/rfc8174</a>>.
+
+ [<a name="ref-RFC8187" id="ref-RFC8187">RFC8187</a>] Reschke, J., "Indicating Character Encoding and Language
+ for HTTP Header Field Parameters", <a href="./rfc8187">RFC 8187</a>,
+ DOI 10.17487/RFC8187, September 2017,
+ <<a href="https://www.rfc-editor.org/info/rfc8187">https://www.rfc-editor.org/info/rfc8187</a>>.
+
+ [<a name="ref-W3C.REC-css3-mediaqueries-20120619" id="ref-W3C.REC-css3-mediaqueries-20120619">W3C.REC-css3-mediaqueries-20120619</a>]
+ Rivoal, F., "Media Queries", W3C Recommendation
+ REC-css3-mediaqueries-20120619, June 2012,
+ <<a href="http://www.w3.org/TR/2012/REC-css3-mediaqueries-20120619">http://www.w3.org/TR/2012/</a>
+ <a href="http://www.w3.org/TR/2012/REC-css3-mediaqueries-20120619">REC-css3-mediaqueries-20120619</a>>.
+
+<span class="h3"><a class="selflink" name="section-7.2" href="#section-7.2">7.2</a>. Informative References</span>
+
+ [<a name="ref-RFC2046" id="ref-RFC2046">RFC2046</a>] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
+ Extensions (MIME) Part Two: Media Types", <a href="./rfc2046">RFC 2046</a>,
+ DOI 10.17487/RFC2046, November 1996,
+ <<a href="https://www.rfc-editor.org/info/rfc2046">https://www.rfc-editor.org/info/rfc2046</a>>.
+
+ [<a name="ref-RFC2818" id="ref-RFC2818">RFC2818</a>] Rescorla, E., "HTTP Over TLS", <a href="./rfc2818">RFC 2818</a>,
+ DOI 10.17487/RFC2818, May 2000,
+ <<a href="https://www.rfc-editor.org/info/rfc2818">https://www.rfc-editor.org/info/rfc2818</a>>.
+
+
+
+
+
+
+<span class="grey">Nottingham Standards Track [Page 17]</span></pre>
+<hr class='noprint' style='width: 96ex;' align='left'/><!--NewPage--><pre class='newpage'><a name="page-18" id="page-18" href="#page-18" class="invisible"> </a>
+<span class="grey"><a href="./rfc8288">RFC 8288</a> Web Linking October 2017</span>
+
+
+ [<a name="ref-RFC4287" id="ref-RFC4287">RFC4287</a>] Nottingham, M., Ed. and R. Sayre, Ed., "The Atom
+ Syndication Format", <a href="./rfc4287">RFC 4287</a>, DOI 10.17487/RFC4287,
+ December 2005, <<a href="https://www.rfc-editor.org/info/rfc4287">https://www.rfc-editor.org/info/rfc4287</a>>.
+
+ [<a name="ref-RFC6265" id="ref-RFC6265">RFC6265</a>] Barth, A., "HTTP State Management Mechanism", <a href="./rfc6265">RFC 6265</a>,
+ DOI 10.17487/RFC6265, April 2011,
+ <<a href="https://www.rfc-editor.org/info/rfc6265">https://www.rfc-editor.org/info/rfc6265</a>>.
+
+ [<a name="ref-W3C.REC-html5-20141028" id="ref-W3C.REC-html5-20141028">W3C.REC-html5-20141028</a>]
+ Hickson, I., Berjon, R., Faulkner, S., Leithead, T.,
+ Navara, E., O'Connor, T., and S. Pfeiffer, "HTML5", W3C
+ Recommendation REC-html5-20141028, October 2014,
+ <<a href="http://www.w3.org/TR/2014/REC-html5-20141028">http://www.w3.org/TR/2014/REC-html5-20141028</a>>.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+<span class="grey">Nottingham Standards Track [Page 18]</span></pre>
+<hr class='noprint' style='width: 96ex;' align='left'/><!--NewPage--><pre class='newpage'><a name="page-19" id="page-19" href="#page-19" class="invisible"> </a>
+<span class="grey"><a href="./rfc8288">RFC 8288</a> Web Linking October 2017</span>
+
+
+<span class="h2"><a class="selflink" name="appendix-A" href="#appendix-A">Appendix A</a>. Notes on Other Link Serialisations</span>
+
+ Header fields (<a href="#section-3">Section 3</a>) are only one serialisation of links; other
+ specifications have defined alternative serialisations.
+
+<span class="h3"><a class="selflink" name="appendix-A.1" href="#appendix-A.1">A.1</a>. Link Serialisation in HTML</span>
+
+ 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.
+
+ 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".
+
+ <a href="#section-4.8">Section 4.8</a> of HTML5 [<a href="#ref-W3C.REC-html5-20141028" title=""HTML5"">W3C.REC-html5-20141028</a>] 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).
+
+ 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).
+
+ 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.
+
+<span class="h3"><a class="selflink" name="appendix-A.2" href="#appendix-A.2">A.2</a>. Link Serialisation in Atom</span>
+
+ Atom [<a href="./rfc4287" title=""The Atom Syndication Format"">RFC4287</a>] 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.
+
+ When serialising an atom:link into a Link header field, it is
+ necessary to convert link targets (if used) to URIs.
+
+
+
+<span class="grey">Nottingham Standards Track [Page 19]</span></pre>
+<hr class='noprint' style='width: 96ex;' align='left'/><!--NewPage--><pre class='newpage'><a name="page-20" id="page-20" href="#page-20" class="invisible"> </a>
+<span class="grey"><a href="./rfc8288">RFC 8288</a> Web Linking October 2017</span>
+
+
+ Atom defines extension relation types in terms of IRIs. This
+ specification redefines them as URIs, to simplify and reduce errors
+ in their comparison.
+
+ Atom allows registered link relation types to be serialised as
+ absolute URIs using a prefix, "<a href="http://www.iana.org/assignments/relation/">http://www.iana.org/assignments/</a>
+ <a href="http://www.iana.org/assignments/relation/">relation/</a>". This prefix is specific to the Atom serialisation.
+
+ 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.
+
+ 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.
+
+ 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.
+
+<span class="h2"><a class="selflink" name="appendix-B" href="#appendix-B">Appendix B</a>. Algorithms for Parsing Link Header Fields</span>
+
+ 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.
+
+ 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.
+
+<span class="h3"><a class="selflink" name="appendix-B.1" href="#appendix-B.1">B.1</a>. Parsing a Header Set for Links</span>
+
+ 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.
+
+ 1. Let field_values be a list containing the members of header_set
+ whose field_name is a case-insensitive match for "link".
+
+ 2. Let links be an empty list.
+
+
+
+
+
+
+<span class="grey">Nottingham Standards Track [Page 20]</span></pre>
+<hr class='noprint' style='width: 96ex;' align='left'/><!--NewPage--><pre class='newpage'><a name="page-21" id="page-21" href="#page-21" class="invisible"> </a>
+<span class="grey"><a href="./rfc8288">RFC 8288</a> Web Linking October 2017</span>
+
+
+ 3. For each field_value in field_values:
+ 1. Let value_links be the result of Parsing a Link Field Value
+ (Appendix B.2) from field_value.
+ 2. Append each member of value_links to links.
+
+ 4. Return links.
+
+<span class="h3"><a class="selflink" name="appendix-B.2" href="#appendix-B.2">B.2</a>. Parsing a Link Field Value</span>
+
+ 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.
+
+ 1. Let links be an empty list.
+
+ 2. While field_value has content:
+ 1. Consume any leading OWS.
+ 2. If the first character is not "<", return links.
+ 3. Discard the first character ("<").
+ 4. Consume up to but not including the first ">" character or
+ end of field_value and let the result be target_string.
+ 5. If the next character is not ">", return links.
+ 6. Discard the leading ">" character.
+ 7. Let link_parameters be the result of Parsing Parameters
+ (Appendix B.3) from field_value (consuming zero or more
+ characters of it).
+ 8. Let target_uri be the result of relatively resolving (as per
+ <a href="./rfc3986#section-5.2">[RFC3986], Section 5.2</a>) target_string. Note that any base
+ URI carried in the payload body is NOT used.
+ 9. 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.
+ 10. Split relations_string on RWS (removing it in the process)
+ into a list of string relation_types.
+ 11. 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 <a href="./rfc7231#section-3.1.4.1">[RFC7231],
+ Section 3.1.4.1</a>, serialised as a URI. Where the URL is
+ anonymous, context_string is null.
+ 12. Let context_uri be the result of relatively resolving (as
+ per <a href="./rfc3986#section-5.2">[RFC3986], Section 5.2</a>) 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.
+ 13. Let target_attributes be an empty list.
+
+
+
+
+
+
+<span class="grey">Nottingham Standards Track [Page 21]</span></pre>
+<hr class='noprint' style='width: 96ex;' align='left'/><!--NewPage--><pre class='newpage'><a name="page-22" id="page-22" href="#page-22" class="invisible"> </a>
+<span class="grey"><a href="./rfc8288">RFC 8288</a> Web Linking October 2017</span>
+
+
+ 14. For each tuple (param_name, param_value) of link_parameters:
+ 1. If param_name matches "rel" or "anchor", skip this
+ tuple.
+ 2. 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.
+ 3. Append (param_name, param_value) to target_attributes.
+ 15. 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 ("*").
+ 16. For each star_param_name in star_param_names:
+ 1. Let base_param_name be star_param_name with the last
+ character removed.
+ 2. 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.
+ 3. Remove all tuples from link_parameters whose first
+ member is base_param_name.
+ 4. Change the first member of all tuples in link_parameters
+ whose first member is star_param_name to
+ base_param_name.
+ 17. For each relation_type in relation_types:
+ 1. Case-normalise relation_type to lowercase.
+ 2. 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.
+
+ 3. Return links.
+
+<span class="h3"><a class="selflink" name="appendix-B.3" href="#appendix-B.3">B.3</a>. Parsing Parameters</span>
+
+ 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.
+
+ 1. Let parameters be an empty list.
+
+ 2. While input has content:
+ 1. Consume any leading OWS.
+ 2. If the first character is not ";", return parameters.
+ 3. Discard the leading ";" character.
+ 4. Consume any leading OWS.
+
+
+
+<span class="grey">Nottingham Standards Track [Page 22]</span></pre>
+<hr class='noprint' style='width: 96ex;' align='left'/><!--NewPage--><pre class='newpage'><a name="page-23" id="page-23" href="#page-23" class="invisible"> </a>
+<span class="grey"><a href="./rfc8288">RFC 8288</a> Web Linking October 2017</span>
+
+
+ 5. Consume up to but not including the first BWS, "=", ";", or
+ "," character, or up to the end of input, and let the result
+ be parameter_name.
+ 6. Consume any leading BWS.
+ 7. If the next character is "=":
+ 1. Discard the leading "=" character.
+ 2. Consume any leading BWS.
+ 3. 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, 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 the last character of parameter_name is an asterisk
+ ("*"), decode parameter_value according to [<a href="./rfc8187" title=""Indicating Character Encoding and Language for HTTP Header Field Parameters"">RFC8187</a>].
+ Continue processing input if an unrecoverable error is
+ encountered.
+ 8. Else:
+ 1. Let parameter_value be an empty string.
+ 9. Case-normalise parameter_name to lowercase.
+ 10. Append (parameter_name, parameter_value) to parameters.
+ 11. Consume any leading OWS.
+ 12. If the next character is "," or the end of input, stop
+ processing input and return parameters.
+
+<span class="h3"><a class="selflink" name="appendix-B.4" href="#appendix-B.4">B.4</a>. Parsing a Quoted String</span>
+
+ This algorithm parses a quoted string, as per <a href="./rfc7230#section-3.2.6">[RFC7230],
+ Section 3.2.6</a>. Given input, an ASCII string, it returns an unquoted
+ string. input is modified to remove the parsed string.
+
+ 1. Let output be an empty string.
+
+ 2. If the first character of input is not DQUOTE, return output.
+
+ 3. Discard the first character.
+
+ 4. While input has content:
+ 1. If the first character is a backslash ("\"):
+ 1. Discard the first character.
+ 2. If there is no more input, return output.
+ 3. Else, consume the first character and append it to
+ output.
+ 2. Else, if the first character is DQUOTE, discard it and return
+ output.
+ 3. Else, consume the first character and append it to output.
+
+ 5. Return output.
+
+
+
+<span class="grey">Nottingham Standards Track [Page 23]</span></pre>
+<hr class='noprint' style='width: 96ex;' align='left'/><!--NewPage--><pre class='newpage'><a name="page-24" id="page-24" href="#page-24" class="invisible"> </a>
+<span class="grey"><a href="./rfc8288">RFC 8288</a> Web Linking October 2017</span>
+
+
+<span class="h2"><a class="selflink" name="appendix-C" href="#appendix-C">Appendix C</a>. Changes from <a href="./rfc5988">RFC 5988</a></span>
+
+ This specification has the following differences from its
+ predecessor, <a href="./rfc5988">RFC 5988</a>:
+
+ o The initial relation type registrations were removed, since
+ they've already been registered by <a href="./rfc5988">RFC 5988</a>.
+ o The introduction has been shortened.
+ o The "Link Relation Application Data" registry has been removed.
+ o Incorporated errata.
+ o Updated references.
+ o Link cardinality was clarified.
+ o Terminology was changed from "target IRI" and "context IRI" to
+ "link target" and "link context", respectively.
+ o Made assigning a URI to registered relation types serialisation
+ specific.
+ o Removed misleading statement that the Link header field is
+ semantically equivalent to HTML and Atom links.
+ o More carefully defined and used "link serialisations" and "link
+ applications."
+ o Clarified the cardinality of target attributes (generically and
+ for "type").
+ o Corrected the default link context for the Link header field, to
+ be dependent upon the identity of the representation (as per
+ <a href="./rfc7231">RFC 7231</a>).
+ o Defined a suggested parsing algorithm for the Link header.
+ o The value space of target attributes and their definition has been
+ specified.
+ o The ABNF has been updated to be compatible with [<a href="./rfc7230" title=""Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing"">RFC7230</a>]. In
+ particular, whitespace is now explicit.
+ o Some parameters on the HTTP header field can now appear as a
+ token.
+ o Parameters on the HTTP header can now be valueless.
+ o Handling of quoted strings is now defined by [<a href="./rfc7230" title=""Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing"">RFC7230</a>].
+ o The "type" header field parameter now needs to be quoted (as
+ "token" does not allow "/").
+
+Author's Address
+
+ Mark Nottingham
+
+ Email: mnot@mnot.net
+ URI: <a href="https://www.mnot.net/">https://www.mnot.net/</a>
+
+
+
+
+
+
+
+
+Nottingham Standards Track [Page 24]
+
+</pre><br />
+ <span class="noprint"><small><small>Html markup produced by rfcmarkup 1.129d, available from
+ <a href="https://tools.ietf.org/tools/rfcmarkup/">https://tools.ietf.org/tools/rfcmarkup/</a>
+ </small></small></span>
+ </div>
+</body>
+</html>
projects / squeep-web-linking / blobdiff