| draft-nottingham-http-link-header-10.txt |  | rfc5988.txt |
--- | --- | --- | --- | ---
| Network Working Group M. Nottingham |  | Network Working Group M. Nottingham |
| Internet-Draft May 5, 2010 |  | Request for Comments: 5988 August 2010 |
| Updates: 4287 (if approved) |  | Updates: 4287 |
| Intended status: Standards Track |  | Category: Standards Track |
| Expires: November 6, 2010 |  |  |
| Web Linking |  | Web Linking |
| draft-nottingham-http-link-header-10 |  |  |
| Abstract |  | Abstract |
| This document specifies relation types for Web links, and defines a |  | This document specifies relation types for Web links, and defines a |
| registry for them. It also defines the use of such links in HTTP |  | registry for them. It also defines the use of such links in HTTP |
| headers with the Link header-field. |  | headers with the Link header field. |
| Status of this Memo |  |  |
| This Internet-Draft is submitted in full conformance with the |  |  |
| provisions of BCP 78 and BCP 79. |  |  |
| Internet-Drafts are working documents of the Internet Engineering |  |  |
| Task Force (IETF). Note that other groups may also distribute |  |  |
| working documents as Internet-Drafts. The list of current Internet- |  |  |
| Drafts is at http://datatracker.ietf.org/drafts/current/. |  |  |
| Internet-Drafts are draft documents valid for a maximum of six months |  | Status of This Memo |
| and may be updated, replaced, or obsoleted by other documents at any |  |  |
| time. It is inappropriate to use Internet-Drafts as reference |  |  |
| material or to cite them other than as "work in progress." |  |  |
| This Internet-Draft will expire on November 6, 2010. |  | This document specifies an Internet standards track protocol for the |
|  |  | Internet community, and requests discussion and suggestions for |
|  |  | improvements. Please refer to the current edition of the "Internet |
|  |  | Official Protocol Standards" (STD 1) for the standardization state |
|  |  | and status of this protocol. Distribution of this memo is unlimited. |
| Copyright Notice |  | Copyright Notice |
| Copyright (c) 2010 IETF Trust and the persons identified as the |  | Copyright (c) 2010 IETF Trust and the persons identified as the |
| document authors. All rights reserved. |  | document authors. All rights reserved. |
| This document is subject to BCP 78 and the IETF Trust's Legal |  | This document is subject to BCP 78 and the IETF Trust's Legal |
| Provisions Relating to IETF Documents |  | Provisions Relating to IETF Documents |
| (http://trustee.ietf.org/license-info) in effect on the date of |  | (http://trustee.ietf.org/license-info) in effect on the date of |
| publication of this document. Please review these documents |  | publication of this document. Please review these documents |
| skipping to change at page 2, line 34 |  | skipping to change at page 2, line 22 |
| 4.2. Extension Relation Types . . . . . . . . . . . . . . . . . 6 |  | 4.2. Extension Relation Types . . . . . . . . . . . . . . . . . 6 |
| 5. The Link Header Field . . . . . . . . . . . . . . . . . . . . 6 |  | 5. The Link Header Field . . . . . . . . . . . . . . . . . . . . 6 |
| 5.1. Target IRI . . . . . . . . . . . . . . . . . . . . . . . . 7 |  | 5.1. Target IRI . . . . . . . . . . . . . . . . . . . . . . . . 7 |
| 5.2. Context IRI . . . . . . . . . . . . . . . . . . . . . . . 7 |  | 5.2. Context IRI . . . . . . . . . . . . . . . . . . . . . . . 7 |
| 5.3. Relation Type . . . . . . . . . . . . . . . . . . . . . . 8 |  | 5.3. Relation Type . . . . . . . . . . . . . . . . . . . . . . 8 |
| 5.4. Target Attributes . . . . . . . . . . . . . . . . . . . . 8 |  | 5.4. Target Attributes . . . . . . . . . . . . . . . . . . . . 8 |
| 5.5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 9 |  | 5.5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 9 |
| 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 |  | 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 |
| 6.1. Link HTTP Header Registration . . . . . . . . . . . . . . 10 |  | 6.1. Link HTTP Header Registration . . . . . . . . . . . . . . 10 |
| 6.2. Link Relation Type Registry . . . . . . . . . . . . . . . 10 |  | 6.2. Link Relation Type Registry . . . . . . . . . . . . . . . 10 |
|  |  | 6.2.1. Registering New Link Relation Types . . . . . . . . . 11 |
|  |  | 6.2.2. Initial Registry Contents . . . . . . . . . . . . . . 12 |
| 6.3. Link Relation Application Data Registry . . . . . . . . . 16 |  | 6.3. Link Relation Application Data Registry . . . . . . . . . 16 |
| 7. Security Considerations . . . . . . . . . . . . . . . . . . . 17 |  | 7. Security Considerations . . . . . . . . . . . . . . . . . . . 17 |
| 8. Internationalisation Considerations . . . . . . . . . . . . . 18 |  | 8. Internationalisation Considerations . . . . . . . . . . . . . 18 |
| 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 |  | 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 |
| 9.1. Normative References . . . . . . . . . . . . . . . . . . . 18 |  | 9.1. Normative References . . . . . . . . . . . . . . . . . . . 19 |
| 9.2. Informative References . . . . . . . . . . . . . . . . . . 19 |  | 9.2. Informative References . . . . . . . . . . . . . . . . . . 19 |
| Appendix A. Link Relation Registry Format . . . . . . . . . . . . 20 |  | Appendix A. Notes on Using the Link Header with the HTML4 |
| A.1. Relax NG Grammar . . . . . . . . . . . . . . . . . . . . . 21 |  | Format . . . . . . . . . . . . . . . . . . . . . . . 21 |
| A.2. Example . . . . . . . . . . . . . . . . . . . . . . . . . 22 |  | Appendix B. Notes on Using the Link Header with the Atom |
| Appendix B. Notes on Using the Link Header with the HTML4 |  |  |
| Format . . . . . . . . . . . . . . . . . . . . . . . 22 |  | Format . . . . . . . . . . . . . . . . . . . . . . . 22 |
| Appendix C. Notes on Using the Link Header with the Atom |  | Appendix C. Acknowledgements . . . . . . . . . . . . . . . . . . 23 |
| Format . . . . . . . . . . . . . . . . . . . . . . . 23 |  |  |
| Appendix D. Acknowledgements . . . . . . . . . . . . . . . . . . 24 |  |  |
| Appendix E. Document history . . . . . . . . . . . . . . . . . . 24 |  |  |
| Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 28 |  |  |
| 1. Introduction |  | 1. Introduction |
| A means of indicating the relationships between resources on the Web, |  | A means of indicating the relationships between resources on the Web, |
| as well as indicating the type of those relationships, has been |  | as well as indicating the type of those relationships, has been |
| available for some time in HTML [W3C.REC-html401-19991224], and more |  | available for some time in HTML [W3C.REC-html401-19991224], and more |
| recently in Atom [RFC4287]. These mechanisms, although conceptually |  | recently in Atom [RFC4287]. These mechanisms, although conceptually |
| similar, are separately specified. However, links between resources |  | similar, are separately specified. However, links between resources |
| need not be format-specific; it can be useful to have typed links |  | need not be format specific; it can be useful to have typed links |
| that are independent of their serialisation, especially when a |  | that are independent of their serialisation, especially when a |
| resource has representations in multiple formats. |  | resource has representations in multiple formats. |
| To this end, this document defines a framework for typed links that |  | To this end, this document defines a framework for typed links that |
| isn't specific to a particular serialisation or application. It does |  | isn't specific to a particular serialisation or application. It does |
| so by re-defining the link relation registry established by Atom to |  | so by redefining the link relation registry established by Atom to |
| have a broader domain, and adding to it the relations that are |  | have a broader domain, and adding to it the relations that are |
| defined by HTML. |  | defined by HTML. |
| Furthermore, an HTTP header-field for conveying typed links was |  | Furthermore, an HTTP header field for conveying typed links was |
| defined in Section 19.6.2.4 of [RFC2068], but removed from [RFC2616], |  | defined in Section 19.6.2.4 of [RFC2068], but removed from [RFC2616], |
| due to a lack of implementation experience. Since then, it has been |  | due to a lack of implementation experience. Since then, it has been |
| implemented in some User-Agents (e.g., for stylesheets), and several |  | implemented in some User Agents (e.g., for stylesheets), and several |
| additional use cases have surfaced. |  | additional use cases have surfaced. |
| Because it was removed, the status of the Link header is unclear, |  | Because it was removed, the status of the Link header is unclear, |
| leading some to consider minting new application-specific HTTP |  | leading some to consider minting new application-specific HTTP |
| headers instead of reusing it. This document addresses this by re- |  | headers instead of reusing it. This document addresses this by re- |
| specifying the Link header as one such serialisation, with updated |  | specifying the Link header as one such serialisation, with updated |
| but backwards-compatible syntax. |  | but backwards-compatible syntax. |
| 2. Notational Conventions |  | 2. Notational Conventions |
| skipping to change at page 3, line 48 |  | skipping to change at page 3, line 48 |
| document are to be interpreted as described in BCP 14, [RFC2119], as |  | document are to be interpreted as described in BCP 14, [RFC2119], as |
| scoped to those conformance targets. |  | scoped to those conformance targets. |
| This document uses the Augmented Backus-Naur Form (ABNF) notation of |  | This document uses the Augmented Backus-Naur Form (ABNF) notation of |
| [RFC2616], and explicitly includes the following rules from it: |  | [RFC2616], and explicitly includes the following rules from it: |
| quoted-string, token, SP (space), LOALPHA, DIGIT. |  | quoted-string, token, SP (space), LOALPHA, DIGIT. |
| Additionally, the following rules are included from [RFC3986]: URI |  | Additionally, the following rules are included from [RFC3986]: URI |
| and URI-Reference; from [RFC4288]: type-name and subtype-name; from |  | and URI-Reference; from [RFC4288]: type-name and subtype-name; from |
| [W3C.REC-html401-19991224]: MediaDesc; from [RFC5646]: Language-Tag; |  | [W3C.REC-html401-19991224]: MediaDesc; from [RFC5646]: Language-Tag; |
| and from [I-D.reschke-rfc2231-in-http], ext-value and parmname. |  | and from [RFC5987], ext-value and parmname. |
| 3. Links |  | 3. Links |
| In this specification, a link is a typed connection between two |  | In this specification, a link is a typed connection between two |
| resources that are identified by IRIs [RFC3987], and is comprised of: |  | resources that are identified by Internationalised Resource |
| o A context IRI, and |  | Identifiers (IRIs) [RFC3987], and is comprised of: |
| o a link relation type (Section 4), and |  |  |
|  |  | o A context IRI, |
|  |  | o a link relation type (Section 4), |
| o a target IRI, and |  | o a target IRI, and |
| o optionally, target attributes. |  | o optionally, target attributes. |
| A link can be viewed as a statement of the form "{context IRI} has a |  | A link can be viewed as a statement of the form "{context IRI} has a |
| {relation type} resource at {target IRI}, which has {target |  | {relation type} resource at {target IRI}, which has {target |
| attributes}." |  | attributes}". |
| Note that in the common case, the context IRI will also be a URI |  | Note that in the common case, the context IRI will also be a URI |
| [RFC3986], because many protocols (such as HTTP) do not support |  | [RFC3986], because many protocols (such as HTTP) do not support |
| dereferencing IRIs. Likewise, the target IRI will be converted to a |  | dereferencing IRIs. Likewise, the target IRI will be converted to a |
| URI (see [RFC3987], Section 3.1) in serialisations that do not |  | URI (see [RFC3987], Section 3.1) in serialisations that do not |
| support IRIs (e.g., the Link header). |  | support IRIs (e.g., the Link header). |
| This specification does not place restrictions on the cardinality of |  | This specification does not place restrictions on the cardinality of |
| links; there can be multiple links from and to a particular IRI, and |  | links; there can be multiple links to and from a particular IRI, and |
| multiple links of different types between two given IRIs. Likewise, |  | multiple links of different types between two given IRIs. Likewise, |
| the relative ordering of links in any particular serialisation, or |  | the relative ordering of links in any particular serialisation, or |
| between serialisations (e.g., the Link header and in-content links) |  | between serialisations (e.g., the Link header and in-content links) |
| is not specified or significant in this specification; applications |  | is not specified or significant in this specification; applications |
| that wish to consider ordering significant can do so. |  | that wish to consider ordering significant can do so. |
| Target attributes are a set of key/value pairs that describe the link |  | Target attributes are a set of key/value pairs that describe the link |
| or its target; for example, a media type hint. This specification |  | or its target; for example, a media type hint. This specification |
| does not attempt to coordinate their names or use, but does provide |  | does not attempt to coordinate their names or use, but does provide |
| common target attributes for use in the Link HTTP header. |  | common target attributes for use in the Link HTTP header. |
| Finally, this specification does not define a general syntax for |  | Finally, this specification does not define a general syntax for |
| expressing links, nor mandate a specific context for any given link; |  | expressing links, nor does it mandate a specific context for any |
| it is expected that serialisations of links will specify both |  | given link; it is expected that serialisations of links will specify |
| aspects. One such serialisation is communication of links through |  | both aspects. One such serialisation is communication of links |
| HTTP headers, specified in Section 5. |  | through HTTP headers, specified in Section 5. |
| 4. Link Relation Types |  | 4. Link Relation Types |
| In the simplest case, a link relation type identifies the semantics |  | In the simplest case, a link relation type identifies the semantics |
| of a link. For example, a link with the relation type "copyright" |  | of a link. For example, a link with the relation type "copyright" |
| indicates that the resource identified by the target IRI is a |  | indicates that the resource identified by the target IRI is a |
| statement of the copyright terms applying to the current context IRI. |  | statement of the copyright terms applying to the current context IRI. |
| Link relation types can also be used to indicate that the target |  | Link relation types can also be used to indicate that the target |
| resource has particular attributes, or exhibits particular |  | resource has particular attributes, or exhibits particular |
| skipping to change at page 5, line 39 |  | skipping to change at page 5, line 43 |
| and MUST be compared character-by-character in a case-insensitive |  | and MUST be compared character-by-character in a case-insensitive |
| fashion. They SHOULD be appropriate to the specificity of the |  | fashion. They SHOULD be appropriate to the specificity of the |
| relation type; i.e., if the semantics are highly specific to a |  | relation type; i.e., if the semantics are highly specific to a |
| particular application, the name should reflect that, so that more |  | particular application, the name should reflect that, so that more |
| general names are available for less specific use. |  | general names are available for less specific use. |
| Registered relation types MUST NOT constrain the media type of the |  | Registered relation types MUST NOT constrain the media type of the |
| context IRI, and MUST NOT constrain the available representation |  | context IRI, and MUST NOT constrain the available representation |
| media types of the target IRI. However, they can specify the |  | media types of the target IRI. However, they can specify the |
| behaviours and properties of the target resource (e.g., allowable |  | behaviours and properties of the target resource (e.g., allowable |
| HTTP methods, request and response media types which must be |  | HTTP methods, request and response media types that must be |
| supported). |  | supported). |
| Additionally, specific applications of linking may require additional |  | Additionally, specific applications of linking may require additional |
| data to be included in the registry. For example, Web browsers might |  | data to be included in the registry. For example, Web browsers might |
| want to know what kinds of links should be downloaded when they |  | want to know what kinds of links should be downloaded when they |
| archive a Web page; if this application-specific information is in |  | archive a Web page; if this application-specific information is in |
| the registry, new link relation types can control this behaviour |  | the registry, new link relation types can control this behaviour |
| without unnecessary coordination. |  | without unnecessary coordination. |
| To accommodate this, per-entry application data can be added to the |  | To accommodate this, per-entry application data can be added to the |
| Link Relation Type Registry, by registering it in the Link Relation |  | Link Relation Type registry, by registering it in the Link Relation |
| Application Data Registry (Section 6.3). |  | Application Data registry (Section 6.3). |
| 4.2. Extension Relation Types |  | 4.2. Extension Relation Types |
| Applications that don't wish to register a relation type can use an |  | Applications that don't wish to register a relation type can use an |
| extension relation type, which is a URI [RFC3986] that uniquely |  | extension relation type, which is a URI [RFC3986] that uniquely |
| identifies the relation type. Although the URI can point to a |  | identifies the relation type. Although the URI can point to a |
| resource that contains a definition of the semantics of the relation |  | resource that contains a definition of the semantics of the relation |
| type, clients SHOULD NOT automatically access that resource to avoid |  | type, clients SHOULD NOT automatically access that resource to avoid |
| overburdening its server. |  | overburdening its server. |
| skipping to change at page 8, line 23 |  | skipping to change at page 8, line 23 |
| context IRI might be "anonymous" (i.e., no context IRI is available). |  | context IRI might be "anonymous" (i.e., no context IRI is available). |
| For instance, this is the case on a 404 response to a GET request. |  | For instance, this is the case on a 404 response to a GET request. |
| 5.3. Relation Type |  | 5.3. Relation Type |
| The relation type of a link is conveyed in the "rel" parameter's |  | The relation type of a link is conveyed in the "rel" parameter's |
| value. The "rel" parameter MUST NOT appear more than once in a given |  | value. The "rel" parameter MUST NOT appear more than once in a given |
| link-value; occurrences after the first MUST be ignored by parsers. |  | link-value; occurrences after the first MUST be ignored by parsers. |
| The "rev" parameter has been used in the past to indicate that the |  | The "rev" parameter has been used in the past to indicate that the |
| semantics of the relationship are in the reverse direction. I.e., a |  | semantics of the relationship are in the reverse direction. That is, |
| link from A to B with REL="X" expresses the same relationship as a |  | 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 |  | link from B to A with REV="X". "rev" is deprecated by this |
| specification because it often confuses authors and readers; in most |  | specification because it often confuses authors and readers; in most |
| cases using a separate relation type is preferable. |  | cases, using a separate relation type is preferable. |
| Note that extension relation types are REQUIRED to be absolute URIs |  | Note that extension relation types are REQUIRED to be absolute URIs |
| in Link headers, and MUST be quoted if they contain a semicolon (";") |  | in Link headers, and MUST be quoted if they contain a semicolon (";") |
| or comma (",") (as these characters are used as delimiters in the |  | or comma (",") (as these characters are used as delimiters in the |
| header itself). |  | header itself). |
| 5.4. Target Attributes |  | 5.4. Target Attributes |
| The "hreflang", "media", "title", "title*", "type" and any link- |  | The "hreflang", "media", "title", "title*", "type", and any link- |
| extension link-params are considered to be target attributes for the |  | extension link-params are considered to be target attributes for the |
| link. |  | link. |
| The "hreflang" parameter, when present, is a hint indicating what the |  | The "hreflang" parameter, when present, is a hint indicating what the |
| language of the result of dereferencing the link should be. Note |  | language of the result of dereferencing the link should be. Note |
| that this is only a hint; for example, it does not override the |  | that this is only a hint; for example, it does not override the |
| Content-Language header of a HTTP response obtained by actually |  | Content-Language header of a HTTP response obtained by actually |
| following the link. Multiple hreflang parameters on a single link- |  | following the link. Multiple "hreflang" parameters on a single link- |
| value indicate that multiple languages are available from the |  | value indicate that multiple languages are available from the |
| indicated resource. |  | indicated resource. |
| The "media" parameter, when present, is used to indicate intended |  | The "media" parameter, when present, is used to indicate intended |
| destination medium or media for style information (see |  | destination medium or media for style information (see |
| [W3C.REC-html401-19991224], Section 6.13). Note that this may be |  | [W3C.REC-html401-19991224], Section 6.13). Note that this may be |
| updated by [W3C.CR-css3-mediaqueries-20090915]). Its value MUST be |  | updated by [W3C.CR-css3-mediaqueries-20090915]). Its value MUST be |
| quoted if it contains a semicolon (";") or comma (","), and there |  | quoted if it contains a semicolon (";") or comma (","), and there |
| MUST NOT be more than one media parameter in a link-value. |  | MUST NOT be more than one "media" parameter in a link-value. |
| The "title" parameter, when present, is used to label the destination |  | The "title" parameter, when present, is used to label the destination |
| of a link such that it can be used as a human-readable identifier |  | 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 |  | (e.g., a menu entry) in the language indicated by the Content- |
| header (if present). The "title" parameter MUST NOT appear more than |  | Language header (if present). The "title" parameter MUST NOT appear |
| once in a given link-value; occurrences after the first MUST be |  | more than once in a given link-value; occurrences after the first |
| ignored by parsers. |  | MUST be ignored by parsers. |
| The "title*" parameter can be used to encode this label in a |  | The "title*" parameter can be used to encode this label in a |
| different character set, and/or contain language information as per |  | different character set, and/or contain language information as per |
| [I-D.reschke-rfc2231-in-http]. The "title*" parameter MUST NOT |  | [RFC5987]. The "title*" parameter MUST NOT appear more than once in |
| appear more than once in a given link-value; occurrences after the |  | a given link-value; occurrences after the first MUST be ignored by |
| first MUST be ignored by parsers. If the parameter does not contain |  | parsers. If the parameter does not contain language information, its |
| language information, its language is indicated by the Content- |  | language is indicated by the Content-Language header (when present). |
| Language header (when present). |  |  |
| If both the "title" and "title*" parameters appear in a link-value, |  | If both the "title" and "title*" parameters appear in a link-value, |
| processors SHOULD use the "title*" parameter's value. |  | processors SHOULD use the "title*" parameter's value. |
| The "type" parameter, when present, is a hint indicating what the |  | The "type" parameter, when present, is a hint indicating what the |
| media type of the result of dereferencing the link should be. Note |  | 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 |  | that this is only a hint; for example, it does not override the |
| Content-Type header of a HTTP response obtained by actually following |  | Content-Type header of a HTTP response obtained by actually following |
| the link. There MUST NOT be more than one type parameter in a link- |  | the link. There MUST NOT be more than one type parameter in a link- |
| value. |  | value. |
| skipping to change at page 10, line 28 |  | skipping to change at page 10, line 28 |
| rel="start http://example.net/relation/other" |  | rel="start http://example.net/relation/other" |
| Here, the link to "http://example.org/" has the registered relation |  | Here, the link to "http://example.org/" has the registered relation |
| type "start" and the extension relation type |  | type "start" and the extension relation type |
| "http://example.net/relation/other". |  | "http://example.net/relation/other". |
| 6. IANA Considerations |  | 6. IANA Considerations |
| 6.1. Link HTTP Header Registration |  | 6.1. Link HTTP Header Registration |
| This specification updates the Message Header Registry entry for |  | This specification updates the Message Header registry entry for |
| "Link" in HTTP [RFC3864] to refer to this document. |  | "Link" in HTTP [RFC3864] to refer to this document. |
| Header field: Link |  | Header field: Link |
| Applicable protocol: http |  | Applicable protocol: http |
| Status: standard |  | Status: standard |
| Author/change controller: |  | Author/change controller: |
| IETF (iesg@ietf.org) |  | IETF (iesg@ietf.org) |
| Internet Engineering Task Force |  | Internet Engineering Task Force |
| Specification document(s): |  | Specification document(s): |
| [ this document ] |  | [RFC5988] |
| 6.2. Link Relation Type Registry |  | 6.2. Link Relation Type Registry |
| This specification establishes the Link Relation Type Registry, and |  | This specification establishes the Link Relation Type registry, and |
| updates Atom [RFC4287] to refer to it in place of the "Registry of |  | updates Atom [RFC4287] to refer to it in place of the "Registry of |
| Link Relations". |  | Link Relations". |
| [[ Note to IESG: Entries in the Atom registry that are not listed |  | The underlying registry data (e.g., the XML file) must include |
| below at the time that IANA implements this change (i.e., those that |  | Simplified BSD License text as described in Section 4.e of the Trust |
| are registered before this document comes into effect) should be |  | Legal Provisions (<http://trustee.ietf.org/license-info>). |
| referred to the Designated Expert. ]] |  |  |
| 6.2.1. Registering new Link Relation Types |  | 6.2.1. Registering New Link Relation Types |
| Relation types are registered on the advice of a Designated Expert |  | Relation types are registered on the advice of a Designated Expert |
| (appointed by the IESG or their delegate), with a Specification |  | (appointed by the IESG or their delegate), with a Specification |
| Required (using terminology from [RFC5226]). |  | Required (using terminology from [RFC5226]). |
| The requirements for registered relation types are described in |  | The requirements for registered relation types are described in |
| Section 4.1. |  | Section 4.1. |
| Registration requests consist of the completed registration template |  | Registration requests consist of the completed registration template |
| below, typically published in an RFC or Open Standard (in the sense |  | below, typically published in an RFC or Open Standard (in the sense |
| skipping to change at page 11, line 28 |  | skipping to change at page 11, line 28 |
| approve registration once they are satisfied that a specification |  | approve registration once they are satisfied that a specification |
| will be published. |  | will be published. |
| Note that relation types can be registered by third parties, if the |  | Note that relation types can be registered by third parties, if the |
| Designated Expert determines that an unregistered relation type is |  | Designated Expert determines that an unregistered relation type is |
| widely deployed and not likely to be registered in a timely manner. |  | widely deployed and not likely to be registered in a timely manner. |
| The registration template is: |  | The registration template is: |
| o Relation Name: |  | o Relation Name: |
| o Description: |  | o Description: |
| o Reference: |  | o Reference: |
| o Notes: [optional] |  | o Notes: [optional] |
| o Application Data: [optional] |  | o Application Data: [optional] |
| Registration requests should be sent to the [TBD]@ietf.org mailing |  | Registration requests should be sent to the link-relations@ietf.org |
| list, marked clearly in the subject line (e.g,. "NEW RELATION |  | mailing list, marked clearly in the subject line (e.g., "NEW RELATION |
| REQUEST"). |  | REQUEST"). |
| Within at most 14 days of the request, the Designated Expert(s) will |  | Within at most 14 days of the request, the Designated Expert(s) will |
| either approve or deny the registration request, communicating this |  | either approve or deny the registration request, communicating this |
| decision to the review list. Denials should include an explanation |  | decision to the review list. Denials should include an explanation |
| and, if applicable, suggestions as to how to make the request |  | and, if applicable, suggestions as to how to make the request |
| successful. |  | successful. |
| Decisions (or lack thereof) made by the Designated Expert can be |  | Decisions (or lack thereof) made by the Designated Expert can be |
| first appealed to Application Area Directors (contactable using |  | first appealed to Application Area Directors (contactable using |
| app-ads@tools.ietf.org email address or directly by looking up their |  | app-ads@tools.ietf.org email address or directly by looking up their |
| email addresses on http://www.iesg.org/ website) and, if the |  | email addresses on http://www.iesg.org/ website) and, if the |
| appellant is not satisfied with the response, to the full IESG (using |  | appellant is not satisfied with the response, to the full IESG (using |
| the iesg@iesg.org mailing list). |  | the iesg@iesg.org mailing list). |
| When a registration request is successful, the Designated Expert(s) |  |  |
| will update the registry XML file (using the format described in |  |  |
| Appendix A including the MIT license) and send it to the [TBD-2]@ |  |  |
| ietf.org mailing list (which SHOULD NOT be centrally archived, so as |  |  |
| to avoid load issues from automated agents, and only accept posts |  |  |
| from the Designated Expert(s)), so that implementers interested in |  |  |
| receiving a machine-readable registry can do so. Simultaneously, |  |  |
| they will send a text (not XML) version of the registry to IANA for |  |  |
| publication. |  |  |
| IANA should only accept registry updates from the Designated |  | IANA should only accept registry updates from the Designated |
| Expert(s), and should direct all requests for registration to the |  | Expert(s), and should direct all requests for registration to the |
| review mailing list. |  | review mailing list. |
| 6.2.2. Initial Registry Contents |  | 6.2.2. Initial Registry Contents |
| The Link Relation Type registry's initial contents are: |  | The Link Relation Type registry's initial contents are: |
| o Relation Name: alternate |  | o Relation Name: alternate |
| o Description: Designates a substitute for the link's context. |  | o Description: Designates a substitute for the link's context. |
| skipping to change at page 13, line 26 |  | skipping to change at page 13, line 20 |
| o Reference: [RFC5023] |  | o Reference: [RFC5023] |
| o Relation Name: enclosure |  | o Relation Name: enclosure |
| o Description: Identifies a related resource that is potentially |  | o Description: Identifies a related resource that is potentially |
| large and might require special handling. |  | large and might require special handling. |
| o Reference: [RFC4287] |  | o Reference: [RFC4287] |
| o Relation Name: first |  | o Relation Name: first |
| o Description: An IRI that refers to the furthest preceding resource |  | o Description: An IRI that refers to the furthest preceding resource |
| in a series of resources. |  | in a series of resources. |
| o Reference: [this document] |  | o Reference: [RFC5988] |
| o Notes: this relation type registration did not indicate a |  | o Notes: this relation type registration did not indicate a |
| reference. Originally requested by Mark Nottingham in December |  | reference. Originally requested by Mark Nottingham in December |
| 2004. |  | 2004. |
| o Relation Name: glossary |  | o Relation Name: glossary |
| o Description: Refers to a glossary of terms. |  | o Description: Refers to a glossary of terms. |
| o Reference: [W3C.REC-html401-19991224] |  | o Reference: [W3C.REC-html401-19991224] |
| o Relation Name: help |  | o Relation Name: help |
| o Description: Refers to a resource offering help (more information, |  | o Description: Refers to a resource offering help (more information, |
| skipping to change at page 14, line 4 |  | skipping to change at page 13, line 44 |
| o Relation Name: hub |  | o Relation Name: hub |
| o Description: Refers to a hub that enables registration for |  | o Description: Refers to a hub that enables registration for |
| notification of updates to the context. |  | notification of updates to the context. |
| o Reference: <http://pubsubhubbub.googlecode.com/> <http:// |  | o Reference: <http://pubsubhubbub.googlecode.com/> <http:// |
| pubsubhubbub.googlecode.com/svn/trunk/pubsubhubbub-core-0.3.html> |  | pubsubhubbub.googlecode.com/svn/trunk/pubsubhubbub-core-0.3.html> |
| o Notes: this relation type was requested by Brett Slatkin. |  | o Notes: this relation type was requested by Brett Slatkin. |
| o Relation Name: index |  | o Relation Name: index |
| o Description: Refers to an index. |  | o Description: Refers to an index. |
| o Reference: [W3C.REC-html401-19991224] |  | o Reference: [W3C.REC-html401-19991224] |
| o Relation Name: last |  | o Relation Name: last |
| o Description: An IRI that refers to the furthest following resource |  | o Description: An IRI that refers to the furthest following resource |
| in a series of resources. |  | in a series of resources. |
| o Reference: [this document] |  | o Reference: [RFC5988] |
| o Notes: this relation type registration did not indicate a |  | o Notes: this relation type registration did not indicate a |
| reference. Originally requested by Mark Nottingham in December |  | reference. Originally requested by Mark Nottingham in December |
| 2004. |  | 2004. |
| o Relation Name: latest-version |  | o Relation Name: latest-version |
| o Description: Points to a resource containing the latest (e.g., |  | o Description: Points to a resource containing the latest (e.g., |
| current) version of the context. |  | current) version of the context. |
| o Reference: [RFC5829] |  | o Reference: [RFC5829] |
| o Relation Name: license |  | o Relation Name: license |
| skipping to change at page 14, line 33 |  | skipping to change at page 14, line 26 |
| o Description: Refers to the next resource in a ordered series of |  | o Description: Refers to the next resource in a ordered series of |
| resources. |  | resources. |
| o Reference: [W3C.REC-html401-19991224] |  | o Reference: [W3C.REC-html401-19991224] |
| o Relation Name: next-archive |  | o Relation Name: next-archive |
| o Description: Refers to the immediately following archive resource. |  | o Description: Refers to the immediately following archive resource. |
| o Reference: [RFC5005] |  | o Reference: [RFC5005] |
| o Relation Name: payment |  | o Relation Name: payment |
| o Description: indicates a resource where payment is accepted. |  | o Description: indicates a resource where payment is accepted. |
| o Reference: [this document] |  | o Reference: [RFC5988] |
| o Notes: this relation type registration did not indicate a |  | o Notes: this relation type registration did not indicate a |
| reference. Requested by Joshua Kinberg and Robert Sayre. It is |  | reference. Requested by Joshua Kinberg and Robert Sayre. It is |
| meant as a general way to facilitate acts of payment, and thus |  | meant as a general way to facilitate acts of payment, and thus |
| this specification makes no assumptions on the type of payment or |  | this specification makes no assumptions on the type of payment or |
| transaction protocol. Examples may include a web page where |  | transaction protocol. Examples may include a Web page where |
| donations are accepted or where goods and services are available |  | donations are accepted or where goods and services are available |
| for purchase. rel="payment" is not intended to initiate an |  | for purchase. rel="payment" is not intended to initiate an |
| automated transaction. In Atom documents, a link element with a |  | automated transaction. In Atom documents, a link element with a |
| rel="payment" attribute may exist at the feed/channel level and/or |  | rel="payment" attribute may exist at the feed/channel level and/or |
| the entry/item level. For example, a rel="payment" link at the |  | the entry/item level. For example, a rel="payment" link at the |
| feed/channel level may point to a "tip jar" URI, whereas an entry/ |  | feed/channel level may point to a "tip jar" URI, whereas an entry/ |
| item containing a book review may include a rel="payment" link |  | item containing a book review may include a rel="payment" link |
| that points to the location where the book may be purchased |  | that points to the location where the book may be purchased |
| through an online retailer. |  | through an online retailer. |
| skipping to change at page 16, line 24 |  | skipping to change at page 16, line 15 |
| o Reference: [W3C.REC-html401-19991224] |  | o Reference: [W3C.REC-html401-19991224] |
| o Relation Name: successor-version |  | o Relation Name: successor-version |
| o Description: Points to a resource containing the successor version |  | o Description: Points to a resource containing the successor version |
| in the version history. |  | in the version history. |
| o Reference: [RFC5829] |  | o Reference: [RFC5829] |
| o Relation Name: up |  | o Relation Name: up |
| o Description: Refers to a parent document in a hierarchy of |  | o Description: Refers to a parent document in a hierarchy of |
| documents. |  | documents. |
| o Reference: [this document] |  | o Reference: [RFC5988] |
| o Notes: this relation type registration did not indicate a |  | o Notes: this relation type registration did not indicate a |
| reference. Requested by Noah Slater. |  | reference. Requested by Noah Slater. |
| o Relation Name: version-history |  | o Relation Name: version-history |
| o Description: points to a resource containing the version history |  | o Description: points to a resource containing the version history |
| for the context. |  | for the context. |
| o Reference: [RFC5829] |  | o Reference: [RFC5829] |
| o Relation Name: via |  | o Relation Name: via |
| o Description: Identifies a resource that is the source of the |  | o Description: Identifies a resource that is the source of the |
| skipping to change at page 16, line 50 |  | skipping to change at page 16, line 41 |
| o Reference: [RFC5829] |  | o Reference: [RFC5829] |
| o Relation Name: working-copy-of |  | o Relation Name: working-copy-of |
| o Description: Points to the versioned resource from which this |  | o Description: Points to the versioned resource from which this |
| working copy was obtained. |  | working copy was obtained. |
| o Reference: [RFC5829] |  | o Reference: [RFC5829] |
| 6.3. Link Relation Application Data Registry |  | 6.3. Link Relation Application Data Registry |
| This specification also establishes the Link Relation Application |  | This specification also establishes the Link Relation Application |
| Field Registry, to allow entries in the Link Relation Type Registry |  | Field registry, to allow entries in the Link Relation Type registry |
| to be extended with application-specific data (hereafter, "app data") |  | to be extended with application-specific data (hereafter, "app data") |
| specific to all instances of a given link relation type. |  | specific to all instances of a given link relation type. |
| Application data is registered on the advice of a Designated Expert |  | Application data is registered on the advice of a Designated Expert |
| (appointed by the IESG or their delegate), with a Specification |  | (appointed by the IESG or their delegate), with a Specification |
| Required (using terminology from [RFC5226]). |  | Required (using terminology from [RFC5226]). |
| Registration requests consist of the completed registration template |  | Registration requests consist of the completed registration template |
| below; |  | below; |
| o Application Name: |  | o Application Name: |
| o Description: |  | o Description: |
| o Default Value: |  | o Default Value: |
| o Notes: [optional] |  | o Notes: [optional] |
| The Description SHOULD identify the value space of the app data. The |  | The Description SHOULD identify the value space of the app data. The |
| Default Value MUST be appropriate to entries which the app data does |  | Default Value MUST be appropriate to entries to which the app data |
| not apply to. |  | does not apply. |
| Entries that pre-date the addition of app data will automatically be |  | Entries that pre-date the addition of app data will automatically be |
| considered to have the default value for that app data; if there are |  | considered to have the default value for that app data; if there are |
| exceptions, the modification of such entries should be coordinated by |  | exceptions, the modification of such entries should be coordinated by |
| the Designated Expert(s), in consultation with the author of the |  | the Designated Expert(s), in consultation with the author of the |
| proposed app data as well as the registrant of the existing entry (if |  | proposed app data as well as the registrant of the existing entry (if |
| possible). |  | possible). |
| Registration requests should be sent to the [TBD]@ietf.org mailing |  | Registration requests should be sent to the link-relations@ietf.org |
| list, marked clearly in the subject line (e.g,. "NEW APP DATA"). |  | mailing list, marked clearly in the subject line (e.g., "NEW APP |
|  |  | DATA"). |
| Within at most 14 days of the request, the Designated Expert will |  | Within at most 14 days of the request, the Designated Expert will |
| either approve or deny the registration request, communicating this |  | either approve or deny the registration request, communicating this |
| decision to the review list. Denials should include an explanation |  | decision to the review list. Denials should include an explanation |
| and, if applicable, suggestions as to how to make the request |  | and, if applicable, suggestions as to how to make the request |
| successful. Registration requests that are undetermined for a period |  | successful. Registration requests that are undetermined for a period |
| longer than 21 days can be brought to the IESG's attention (using the |  | longer than 21 days can be brought to the IESG's attention (using the |
| iesg@iesg.org mailing list) for resolution. |  | iesg@iesg.org mailing list) for resolution. |
| When a registration request is successful, the Designated Expert will |  | When a registration request is successful, the Designated Expert will |
| forward it to IANA for publication. IANA should only accept registry |  | forward it to IANA for publication. IANA should only accept registry |
| updates from the Designated Expert(s), and should direct all requests |  | updates from the Designated Expert(s), and should direct all requests |
| for registration to the review mailing list. |  | for registration to the review mailing list. |
| 7. Security Considerations |  | 7. Security Considerations |
| The content of the Link header-field is not secure, private or |  | The content of the Link header field is not secure, private or |
| integrity-guaranteed, and due caution should be exercised when using |  | integrity-guaranteed, and due caution should be exercised when using |
| it. Use of TLS with HTTP ([RFC2818] and [RFC2817]) is currently the |  | it. Use of Transport Layer Security (TLS) with HTTP ([RFC2818] and |
| only end-to-end way to provide such protection. |  | [RFC2817]) is currently the only end-to-end way to provide such |
|  |  | protection. |
| Applications that take advantage of typed links should consider the |  | Applications that take advantage of typed links should consider the |
| attack vectors opened by automatically following, trusting, or |  | attack vectors opened by automatically following, trusting, or |
| otherwise using links gathered from HTTP headers. In particular, |  | otherwise using links gathered from HTTP headers. In particular, |
| Link headers that use the "anchor" parameter to associate a link's |  | Link headers that use the "anchor" parameter to associate a link's |
| context with another resource should be treated with due caution. |  | context with another resource should be treated with due caution. |
| The Link entity-header field makes extensive use of IRIs and URIs. |  | The Link entity-header field makes extensive use of IRIs and URIs. |
| See [RFC3987] for security considerations relating to IRIs. See |  | See [RFC3987] for security considerations relating to IRIs. See |
| [RFC3986] for security considerations relating to URIs. See |  | [RFC3986] for security considerations relating to URIs. See |
| skipping to change at page 18, line 32 |  | skipping to change at page 19, line 9 |
| there. |  | there. |
| Relation types are defined as URIs, not IRIs, to aid in their |  | Relation types are defined as URIs, not IRIs, to aid in their |
| comparison. It is not expected that they will be displayed to end |  | comparison. It is not expected that they will be displayed to end |
| users. |  | users. |
| 9. References |  | 9. References |
| 9.1. Normative References |  | 9.1. Normative References |
| [I-D.reschke-rfc2231-in-http] |  |  |
| Reschke, J., "Character Set and Language Encoding for |  |  |
| Hypertext Transfer Protocol (HTTP) Header Field |  |  |
| Parameters", draft-reschke-rfc2231-in-http-12 (work in |  |  |
| progress), April 2010. |  |  |
| [RFC2026] Bradner, S., "The Internet Standards Process -- Revision |  | [RFC2026] Bradner, S., "The Internet Standards Process -- Revision |
| 3", BCP 9, RFC 2026, October 1996. |  | 3", BCP 9, RFC 2026, October 1996. |
| [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate |  | [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate |
| Requirement Levels", BCP 14, RFC 2119, March 1997. |  | Requirement Levels", BCP 14, RFC 2119, March 1997. |
| [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., |  | [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., |
| Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext |  | Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext |
| Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. |  | Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. |
| skipping to change at page 19, line 23 |  | skipping to change at page 19, line 40 |
| [RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and |  | [RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and |
| Registration Procedures", BCP 13, RFC 4288, December 2005. |  | Registration Procedures", BCP 13, RFC 4288, December 2005. |
| [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an |  | [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an |
| IANA Considerations Section in RFCs", BCP 26, RFC 5226, |  | IANA Considerations Section in RFCs", BCP 26, RFC 5226, |
| May 2008. |  | May 2008. |
| [RFC5646] Phillips, A. and M. Davis, "Tags for Identifying |  | [RFC5646] Phillips, A. and M. Davis, "Tags for Identifying |
| Languages", BCP 47, RFC 5646, September 2009. |  | Languages", BCP 47, RFC 5646, September 2009. |
|  |  | [RFC5987] Reschke, J., "Character Set and Language Encoding for |
|  |  | Hypertext Transfer Protocol (HTTP) Header Field |
|  |  | Parameters", RFC 5987, August 2010. |
| 9.2. Informative References |  | 9.2. Informative References |
| [RFC2068] Fielding, R., Gettys, J., Mogul, J., Nielsen, H., and T. |  | [RFC2068] Fielding, R., Gettys, J., Mogul, J., Nielsen, H., and T. |
| Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", |  | Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", |
| RFC 2068, January 1997. |  | RFC 2068, January 1997. |
| [RFC2817] Khare, R. and S. Lawrence, "Upgrading to TLS Within |  | [RFC2817] Khare, R. and S. Lawrence, "Upgrading to TLS Within |
| HTTP/1.1", RFC 2817, May 2000. |  | HTTP/1.1", RFC 2817, May 2000. |
| [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. |  | [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. |
| skipping to change at page 20, line 49 |  | skipping to change at page 21, line 20 |
| [W3C.REC-xhtml-basic-20080729] |  | [W3C.REC-xhtml-basic-20080729] |
| Baker, M., Ishikawa, M., Stark, P., Matsui, S., Wugofski, |  | Baker, M., Ishikawa, M., Stark, P., Matsui, S., Wugofski, |
| T., and T. Yamakami, "XHTML[TM] Basic 1.1", W3C |  | T., and T. Yamakami, "XHTML[TM] Basic 1.1", W3C |
| Recommendation REC-xhtml-basic-20080729, July 2008, |  | Recommendation REC-xhtml-basic-20080729, July 2008, |
| <http://www.w3.org/TR/2008/REC-xhtml-basic-20080729>. |  | <http://www.w3.org/TR/2008/REC-xhtml-basic-20080729>. |
| Latest version available at |  | Latest version available at |
| <http://www.w3.org/TR/xhtml-basic>. |  | <http://www.w3.org/TR/xhtml-basic>. |
| Appendix A. Link Relation Registry Format |  | Appendix A. Notes on Using the Link Header with the HTML4 Format |
| To facilitate applications that wish to use registry data in an |  |  |
| automated fashion, this specification defines an XML-based format for |  |  |
| the registry entries. |  |  |
| Each registered relation type is represented by a RelationType |  |  |
| element, and if any of the app data values are other than the default |  |  |
| value identified in the Application Data Registry, they will be |  |  |
| represented by appdata elements. |  |  |
| Note that this format is NOT that which IANA publishes the registry |  |  |
| in, because doing so would subject IANA's servers to, potentially, |  |  |
| very high load (e.g., if Web browsers were to automatically update |  |  |
| their copies of the registry). Instead, this format is published to |  |  |
| the [TBD-2]@ietf.org mailing list, so that interested implementors |  |  |
| can subscribe and distribute the machine-readable document using |  |  |
| their own infrastructure. |  |  |
| A.1. Relax NG Grammar |  |  |
| element RelationTypes { |  |  |
| element RelationType { |  |  |
| attribute name { text }, |  |  |
| attribute reference { text }, |  |  |
| element description { text }, |  |  |
| element notes { text }?, |  |  |
| element appdata { |  |  |
| attribute name { text }, |  |  |
| text |  |  |
| }* |  |  |
| }+ |  |  |
| } |  |  |
| A.2. Example |  |  |
| <RelationTypes> |  |  |
| <!-- |  |  |
| Copyright (c) <year> The IETF Trust |  |  |
| Permission is hereby granted, free of charge, to any person obtaining |  |  |
| a copy of this software and associated documentation files (the |  |  |
| "Software"), to deal in the Software without restriction, including |  |  |
| without limitation the rights to use, copy, modify, merge, publish, |  |  |
| distribute, sublicense, and/or sell copies of the Software, and to |  |  |
| permit persons to whom the Software is furnished to do so, subject to |  |  |
| the following conditions: |  |  |
| The above copyright notice and this permission notice shall be |  |  |
| included in all copies or substantial portions of the Software. |  |  |
| THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, |  |  |
| EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF |  |  |
| MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND |  |  |
| NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS |  |  |
| BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN |  |  |
| ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN |  |  |
| CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE |  |  |
| SOFTWARE. |  |  |
| --> |  |  |
| <RelationType name="example" |  |  |
| reference="http://www.example.org/example_spec"> |  |  |
| <description>This is an example relation type.</description> |  |  |
| <appdata name="foo">This is the value of Foo.</appdata> |  |  |
| </RelationType> |  |  |
| <!-- ... --> |  |  |
| </RelationTypes> |  |  |
| Appendix B. Notes on Using the Link Header with the HTML4 Format |  |  |
| HTML motivated the original syntax of the Link header, and many of |  | HTML motivated the original syntax of the Link header, and many of |
| the design decisions in this document are driven by a desire to stay |  | the design decisions in this document are driven by a desire to stay |
| compatible with these uses. |  | compatible with these uses. |
| In HTML4, the link element can be mapped to links as specified here |  | In HTML4, the link element can be mapped to links as specified here |
| by using the "href" attribute for the target URI, and "rel" to convey |  | by using the "href" attribute for the target URI, and "rel" to convey |
| the relation type, as in the Link header. The context of the link is |  | the relation type, as in the Link header. The context of the link is |
| the URI associated with the entire HTML document. |  | the URI associated with the entire HTML document. |
| All of the link relation types defined by HTML4 have been included in |  | All of the link relation types defined by HTML4 have been included in |
| the link relation type registry, so they can be used without |  | the Link Relation Type registry, so they can be used without |
| modification. However, there are several potential ways to serialise |  | modification. However, there are several potential ways to serialise |
| extension relation types into HTML4, including |  | extension relation types into HTML4, including |
| o As absolute URIs, or |  | o As absolute URIs, |
| o using the document-wide "profile" attribute's URI as a prefix for |  | o using the document-wide "profile" attribute's URI as a prefix for |
| relation types, or |  | relation types, or |
| o using the RDFa [W3C.REC-rdfa-syntax-20081014] convention of |  | o using the RDFa [W3C.REC-rdfa-syntax-20081014] convention of |
| mapping token prefixes to URIs (in a manner similar to XML name |  | mapping token prefixes to URIs (in a manner similar to XML name |
| spaces) (note that RDFa is only defined to work in XHTML |  | spaces) (note that RDFa is only defined to work in XHTML |
| [W3C.REC-xhtml-basic-20080729], but is sometimes used in HTML4). |  | [W3C.REC-xhtml-basic-20080729], but is sometimes used in HTML4). |
| Individual applications of linking will therefore need to define how |  | Individual applications of linking will therefore need to define how |
| their extension links should be serialised into HTML4. |  | their extension links should be serialised into HTML4. |
| Surveys of existing HTML content have shown that unregistered link |  | Surveys of existing HTML content have shown that unregistered link |
| relation types that are not URIs are (perhaps inevitably) common. |  | relation types that are not URIs are (perhaps inevitably) common. |
| skipping to change at page 23, line 35 |  | skipping to change at page 22, line 18 |
| HTML4 also defines several attributes on links that are not |  | HTML4 also defines several attributes on links that are not |
| explicitly defined by the Link header. These attributes can be |  | explicitly defined by the Link header. These attributes can be |
| serialised as link-extensions to maintain fidelity. |  | serialised as link-extensions to maintain fidelity. |
| Finally, the HTML4 specification gives a special meaning when the |  | Finally, the HTML4 specification gives a special meaning when the |
| "alternate" and "stylesheet" relation types coincide in the same |  | "alternate" and "stylesheet" relation types coincide in the same |
| link. Such links should be serialised in the Link header using a |  | link. Such links should be serialised in the Link header using a |
| single list of relation-types (e.g., rel="alternate stylesheet") to |  | single list of relation-types (e.g., rel="alternate stylesheet") to |
| preserve this relationship. |  | preserve this relationship. |
| Appendix C. Notes on Using the Link Header with the Atom Format |  | Appendix B. Notes on Using the Link Header with the Atom Format |
| Atom conveys links in the atom:link element, with the "href" |  | Atom conveys links in the atom:link element, with the "href" |
| attribute indicating the target IRI and the "rel" attribute |  | attribute indicating the target IRI and the "rel" attribute |
| containing the relation type. The context of the link is either a |  | containing the relation type. The context of the link is either a |
| feed IRI or an entry ID, depending on where it appears; generally, |  | feed IRI or an entry ID, depending on where it appears; generally, |
| feed-level links are obvious candidates for transmission as a Link |  | feed-level links are obvious candidates for transmission as a Link |
| header. |  | header. |
| When serialising an atom:link into a Link header, it is necessary to |  | When serialising an atom:link into a Link header, it is necessary to |
| convert target IRIs (if used) to URIs. |  | convert target IRIs (if used) to URIs. |
| skipping to change at page 24, line 13 |  | skipping to change at page 22, line 42 |
| in their comparison. |  | in their comparison. |
| Atom allows registered link relation types to be serialised as |  | Atom allows registered link relation types to be serialised as |
| absolute URIs. Such relation types SHOULD be converted to the |  | absolute URIs. Such relation types SHOULD be converted to the |
| appropriate registered form (e.g., |  | appropriate registered form (e.g., |
| "http://www.iana.org/assignments/relation/self" to "self") so that |  | "http://www.iana.org/assignments/relation/self" to "self") so that |
| they are not mistaken for extension relation types. |  | they are not mistaken for extension relation types. |
| Furthermore, Atom link relation types are always compared in a case- |  | Furthermore, Atom link relation types are always compared in a case- |
| sensitive fashion; therefore, registered link relation types SHOULD |  | sensitive fashion; therefore, registered link relation types SHOULD |
| be converted to their registered form (usually, lower case) when |  | be converted to their registered form (usually, lowercase) when |
| serialised in an Atom document. |  | serialised in an Atom document. |
| Note also that while the Link header allows multiple relations to be |  | Note also that while the Link header allows multiple relations to be |
| serialised in a single link, atom:link does not. In this case, a |  | serialised in a single link, atom:link does not. In this case, a |
| single link-value may map to several atom:link elements. |  | single link-value may map to several atom:link elements. |
| As with HTML, atom:link defines some attributes that are not |  | As with HTML, atom:link defines some attributes that are not |
| explicitly mirrored in the Link header syntax, but they can also be |  | explicitly mirrored in the Link header syntax, but they can also be |
| used as link-extensions to maintain fidelity. |  | used as link-extensions to maintain fidelity. |
| Appendix D. Acknowledgements |  | Appendix C. Acknowledgements |
| This specification lifts the idea and definition for the Link header |  | This specification lifts the idea and definition for the Link header |
| from RFC2068; credit for it belongs entirely to the authors of and |  | from RFC 2068; credit for it belongs entirely to the authors of and |
| contributors to that document. The link relation type registrations |  | contributors to that document. The link relation type registrations |
| themselves are sourced from several documents; see the applicable |  | themselves are sourced from several documents; see the applicable |
| references. |  | references. |
| The author would like to thank the many people who commented upon, |  | The author would like to thank the many people who commented upon, |
| encouraged and gave feedback to this specification, especially |  | encouraged and gave feedback to this specification, especially |
| including Frank Ellermann, Roy Fielding, Eran Hammer-Lahav, and |  | including Frank Ellermann, Roy Fielding, Eran Hammer-Lahav, and |
| Julian Reschke. |  | Julian Reschke. |
| Appendix E. Document history |  |  |
| [[ to be removed by the RFC editor before publication as an RFC. ]] |  |  |
| -10 (result of IESG review) |  |  |
| o Clarified media BNF. |  |  |
| o Added various security considerations. |  |  |
| o Updated registration procedures. |  |  |
| o Added more detail to 'payment' relation. |  |  |
| o Corrected 'hub' relation. |  |  |
| -09 |  |  |
| o Corrected ptoken / ptokenchar BNF. |  |  |
| o Disallow multiple title* parameters. |  |  |
| o Prefer title* over title when available. |  |  |
| o Remove "\" from ptokenchar. |  |  |
| o Explain why mailing list isn't archived. |  |  |
| o Define default language for title and title*, based on Content- |  |  |
| Language (when present). |  |  |
| o Adjust MAY requirements. |  |  |
| -08 |  |  |
| o Licensed machine-readable data under MIT. |  |  |
| o Clarified URI comparison for extension relation types. |  |  |
| o Various editorial tweaks (thanks, Julian!). |  |  |
| o Changed "fields" to "appdata" to avoid confusion, and add example |  |  |
| to clarify. |  |  |
| o Defined REV according to HTML2, deprecated. |  |  |
| o Clarified allowable characters in link-extensions. |  |  |
| o Changed RFC2231 reference to draft-reschke-rfc2231-in-http. |  |  |
| o Added hub, latest-version, predecessor-version, successor-version, |  |  |
| version-history, working-copy and working-copy-of relation types |  |  |
| to initial registry. |  |  |
| o Adjusted text regarding when anchor parameter is appropriate. |  |  |
| -07 |  |  |
| o Allowed multiple spaces between relation types. |  |  |
| o Relaxed requirements for registered relations. |  |  |
| o Removed Defining New Link Serialisations appendix. |  |  |
| o Added Field registry. |  |  |
| o Added registry XML format. |  |  |
| o Changed registration procedure to use mailing list(s), giving the |  |  |
| Designated Experts more responsibility for the smooth running of |  |  |
| the registry. |  |  |
| o Loosened prohibition against media-specific relation types to |  |  |
| SHOULD NOT. |  |  |
| o Disallowed registration of media-specific relation types (can |  |  |
| still be used as extension types). |  |  |
| o Clarified that parsers are responsible for resolving relative |  |  |
| URIs. |  |  |
| o Fixed ABNF for extended-initial-value. |  |  |
| o Fixed title* parameter quoting in example. |  |  |
| o Added notes for registered relations that lack a reference. |  |  |
| o Added hreflang parameter. |  |  |
| o Clarified status of 'rev'. |  |  |
| o Removed advice to use @profile in HTML4. |  |  |
| o Clarified what multiple *title and hreflang attributes mean. |  |  |
| o Disallowed multiple type, rel and title attributes. |  |  |
| o Removed text about absolute URI form of registered relations. |  |  |
| o Required registered relations to conform to sgml-name (now just |  |  |
| rel-relation-type). |  |  |
| o Required registered relations to be lowercase. |  |  |
| o Made comparison of extension relations case insensitive. |  |  |
| o Clarified requirements on registered relation types regarding |  |  |
| media types, etc. |  |  |
| o Allowed applications to ignore links with anchor parameters if |  |  |
| they're concerned. |  |  |
| o Made 'rev' text a bit less confusing. |  |  |
| o Extension relation URIs SHOULD be all-lowercase. |  |  |
| o Added media parameter. |  |  |
| o Required applications to specifically call out use of anchor |  |  |
| parameter. |  |  |
| -06 |  |  |
| o Added "up" and "service" relation types. |  |  |
| o Fixed "type" attribute syntax and added prose. |  |  |
| o Added note about RDFa and XHTML to HTML4 notes. |  |  |
| o Removed specific location for the registry, since IANA seems to |  |  |
| have its own ideas about that. |  |  |
| -05 |  |  |
| o Clarified how to resolve relative URIs in the 'anchor' parameter. |  |  |
| o Tweaked language about dereferencing relation type URIs. |  |  |
| o Separated out examples. |  |  |
| o Made target-parameters more explicit in the model. |  |  |
| o Discourage special semantics between different relations, or based |  |  |
| upon cardinality. |  |  |
| o Grandfathered in special semantics of 'alternate stylesheet' for |  |  |
| HTML4. |  |  |
| o Note that extension types can be serialised in ways other than as |  |  |
| URIs, as long as they can be converted to URIs. |  |  |
| o Change default context of a link header to that of the requested |  |  |
| resource. |  |  |
| o Use this document as reference for relations that don't have a |  |  |
| formal definition other than the registry entries; avoids circular |  |  |
| references. |  |  |
| o Noted that ordering of links is not significant or defined in this |  |  |
| spec, but may be in specific applications. |  |  |
| o Adjusted uses of 'application' to 'serialisation' where |  |  |
| appropriate. |  |  |
| o Added 'Defining New Link Serialisations' section. |  |  |
| o Added note about case sensitivity when comparing registered |  |  |
| relation types in Atom. |  |  |
| -04 |  |  |
| o Defined context as a resource, rather than a representation. |  |  |
| o Removed concept of link directionality; relegated to a deprecated |  |  |
| Link header extension. |  |  |
| o Relation types split into registered (non-URI) and extension |  |  |
| (URI). |  |  |
| o Changed wording around finding URIs for registered relation types. |  |  |
| o Changed target and context URIs to IRIs (but not extension |  |  |
| relation types). |  |  |
| o Add RFC2231 encoding for title parameter, explicit BNF for title*. |  |  |
| o Add i18n considerations. |  |  |
| o Specify how to compare relation types. |  |  |
| o Changed registration procedure to Designated Expert. |  |  |
| o Softened language around presence of relations in the registry. |  |  |
| o Added describedby relation. |  |  |
| o Re-added 'anchor' parameter, along with security consideration for |  |  |
| third-party anchors. |  |  |
| o Softened language around HTML4 attributes that aren't directly |  |  |
| accommodated. |  |  |
| o Various tweaks to abstract, introduction and examples. |  |  |
| -03 |  |  |
| o Inverted focus from Link headers to link relations. |  |  |
| o Specified was a link relation type is. |  |  |
| o Based on discussion, re-added 'rev'. |  |  |
| o Changed IESG Approval to IETF Consensus for relation registrations |  |  |
| (i.e., require a document). |  |  |
| o Updated RFC2434 reference to RFC5226. |  |  |
| o Registered relations SHOULD conform to sgml-name. |  |  |
| o Cautioned against confusing relation types with media types. |  |  |
| -02 |  |  |
| o Dropped XLink language. |  |  |
| o Removed 'made' example. |  |  |
| o Removed 'rev'. Can still be used as an extension. |  |  |
| o Added HTML reference to introduction. |  |  |
| o Required relationship values that have a ; or , to be quoted. |  |  |
| o Changed base URI for relation values. |  |  |
| o Noted registry location. |  |  |
| o Added advisory text about HTML profile URIs. |  |  |
| o Disallowed registration of relations that only differ in case. |  |  |
| o Clarified language about IRIs in Atom. |  |  |
| o Added descriptions for 'first', 'last', and 'payment', referring |  |  |
| to current IANA registry entries, as these were sourced from |  |  |
| e-mail. Will this cause self-referential implosion? |  |  |
| o Explicitly updates RFC4287. |  |  |
| o Added 'type' parameter. |  |  |
| o Removed unnecessary advice about non-HTML relations in HTML |  |  |
| section. |  |  |
| -01 |  |  |
| o Changed syntax of link-relation to one or more URI; dropped |  |  |
| Profile. |  |  |
| o Dropped anchor parameter; can still be an extension. |  |  |
| o Removed Link-Template header; can be specified by templates spec |  |  |
| or elsewhere. |  |  |
| o Straw-man for link relation registry. |  |  |
| -00 |  |  |
| o Initial draft; normative text lifted from RFC2068. |  |  |
| Author's Address |  | Author's Address |
| Mark Nottingham |  | Mark Nottingham |
| Email: mnot@mnot.net |  | EMail: mnot@mnot.net |
| URI: http://www.mnot.net/ |  | URI: http://www.mnot.net/ |
End of changes. 66 change blocks.
| 358 lines changed or deleted |  | 100 lines changed or added |
This html diff was produced by rfcdiff 1.38. The latest version is available from http://tools.ietf.org/tools/rfcdiff/