| draft-nottingham-http-link-header-04.txt |  | draft-nottingham-http-link-header-05.txt |
--- | --- | --- | --- | ---
| Network Working Group M. Nottingham |  | Network Working Group M. Nottingham |
| Updates: 4287 (if approved) |  | Updates: 4287 (if approved) |
| Intended status: Standards Track |  | Intended status: Standards Track |
| Expires: August 29, 2009 |  | Expires: October 19, 2009 |
| Link Relations and HTTP Header Linking |  | Web Linking |
| draft-nottingham-http-link-header-04 |  | draft-nottingham-http-link-header-05 |
| Status of this Memo |  | Status of this Memo |
| This Internet-Draft is submitted to IETF in full conformance with the |  | This Internet-Draft is submitted to IETF in full conformance with the |
| provisions of BCP 78 and BCP 79. This document may contain material |  | provisions of BCP 78 and BCP 79. This document may contain material |
| from IETF Documents or IETF Contributions published or made publicly |  | from IETF Documents or IETF Contributions published or made publicly |
| available before November 10, 2008. The person(s) controlling the |  | available before November 10, 2008. The person(s) controlling the |
| copyright in some of this material may not have granted the IETF |  | copyright in some of this material may not have granted the IETF |
| Trust the right to allow modifications of such material outside the |  | Trust the right to allow modifications of such material outside the |
| IETF Standards Process. Without obtaining an adequate license from |  | IETF Standards Process. Without obtaining an adequate license from |
| skipping to change at page 1, line 43 |  | skipping to change at page 1, line 43 |
| and may be updated, replaced, or obsoleted by other documents at any |  | and may be updated, replaced, or obsoleted by other documents at any |
| time. It is inappropriate to use Internet-Drafts as reference |  | time. It is inappropriate to use Internet-Drafts as reference |
| material or to cite them other than as "work in progress." |  | material or to cite them other than as "work in progress." |
| The list of current Internet-Drafts can be accessed at |  | The list of current Internet-Drafts can be accessed at |
| http://www.ietf.org/ietf/1id-abstracts.txt. |  | http://www.ietf.org/ietf/1id-abstracts.txt. |
| The list of Internet-Draft Shadow Directories can be accessed at |  | The list of Internet-Draft Shadow Directories can be accessed at |
| http://www.ietf.org/shadow.html. |  | http://www.ietf.org/shadow.html. |
| This Internet-Draft will expire on August 29, 2009. |  | This Internet-Draft will expire on October 19, 2009. |
| Copyright Notice |  | Copyright Notice |
| Copyright (c) 2009 IETF Trust and the persons identified as the |  | Copyright (c) 2009 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 in effect on the date of |  | Provisions Relating to IETF Documents in effect on the date of |
| publication of this document (http://trustee.ietf.org/license-info). |  | publication of this document (http://trustee.ietf.org/license-info). |
| Please review these documents carefully, as they describe your rights |  | Please review these documents carefully, as they describe your rights |
| skipping to change at page 2, line 21 |  | skipping to change at page 2, line 21 |
| 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 how to send such links in HTTP |  | registry for them. It also defines how to send such links in HTTP |
| headers with the Link header-field. |  | headers with the Link header-field. |
| Table of Contents |  | Table of Contents |
| 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 |  | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 |
| 2. Notational Conventions . . . . . . . . . . . . . . . . . . . . 3 |  | 2. Notational Conventions . . . . . . . . . . . . . . . . . . . . 3 |
| 3. Links . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 |  | 3. Links . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 |
| 4. Link Relation Types . . . . . . . . . . . . . . . . . . . . . 4 |  | 4. Link Relation Types . . . . . . . . . . . . . . . . . . . . . 4 |
| 5. The Link Header Field . . . . . . . . . . . . . . . . . . . . 5 |  | 4.1. Registered Relation Types . . . . . . . . . . . . . . . . 5 |
| 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 |  | 4.2. Extension Relation Types . . . . . . . . . . . . . . . . . 6 |
| 7. Security Considerations . . . . . . . . . . . . . . . . . . . 11 |  | 5. The Link Header Field . . . . . . . . . . . . . . . . . . . . 6 |
| 8. Internationalisation Considerations . . . . . . . . . . . . . 11 |  | 5.1. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 7 |
| 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 |  | 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 |
| 9.1. Normative References . . . . . . . . . . . . . . . . . . . 12 |  | 6.1. Link Header Registration . . . . . . . . . . . . . . . . . 8 |
| 9.2. Informative References . . . . . . . . . . . . . . . . . . 12 |  | 6.2. Link Relation Type Registry . . . . . . . . . . . . . . . 8 |
| Appendix A. Notes on Using the Link Header with HTML4 . . . . . . 13 |  | 7. Security Considerations . . . . . . . . . . . . . . . . . . . 12 |
| Appendix B. Notes on Using the Link Header with Atom . . . . . . 14 |  | 8. Internationalisation Considerations . . . . . . . . . . . . . 12 |
| Appendix C. Acknowledgements . . . . . . . . . . . . . . . . . . 15 |  | 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 |
| Appendix D. Document history . . . . . . . . . . . . . . . . . . 15 |  | 9.1. Normative References . . . . . . . . . . . . . . . . . . . 13 |
| Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 17 |  | 9.2. Informative References . . . . . . . . . . . . . . . . . . 14 |
|  |  | Appendix A. Notes on Using the Link Header with HTML4 . . . . . . 14 |
|  |  | Appendix B. Notes on Using the Link Header with Atom . . . . . . 15 |
|  |  | Appendix C. Defining New Link Serialisations . . . . . . . . . . 16 |
|  |  | Appendix D. Acknowledgements . . . . . . . . . . . . . . . . . . 16 |
|  |  | Appendix E. Document history . . . . . . . . . . . . . . . . . . 17 |
|  |  | Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 19 |
| 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 the format, especially when a resource has |  | that are independent of their serialisation, especially when a |
| 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 context of use. It |  | isn't specific to a particular serialisation. It does so by re- |
| does so by re-defining the link relation registry established by Atom |  | defining the link relation registry established by Atom to have a |
| to have a broader scope, and adding to it the relations that are |  | broader scope, and adding to it the relations that are defined by |
| defined by HTML. |  | HTML. |
| Furthermore, an HTTP header-field for conveying typed links was |  | Furthermore, an HTTP header-field for conveying typed links was |
| defined in [RFC2068], but removed from [RFC2616], due to a lack of |  | defined in [RFC2068], but removed from [RFC2616], due to a lack of |
| implementation experience. Since then, it has been implemented in |  | implementation experience. Since then, it has been implemented in |
| some User-Agents (e.g., for stylesheets), and several additional use |  | some User-Agents (e.g., for stylesheets), and several additional use |
| cases have surfaced. Because it was removed, the status of the Link |  | cases have surfaced. |
| header is unclear, leading some to consider minting new application- |  |  |
| specific HTTP headers instead of reusing it. This document addresses |  | Because it was removed, the status of the Link header is unclear, |
| this by re-specifying the Link header with updated but backwards- |  | leading some to consider minting new application-specific HTTP |
| compatible syntax. |  | headers instead of reusing it. This document addresses this by re- |
|  |  | specifying the Link header as one such serialisation, with updated |
|  |  | but backwards-compatible syntax. |
| [[ Feedback is welcome on the ietf-http-wg@w3.org mailing list, |  | [[ Feedback is welcome on the ietf-http-wg@w3.org mailing list, |
| although this is NOT a work item of the HTTPBIS WG. ]] |  | although this is NOT a work item of the HTTPBIS WG. ]] |
| 2. Notational Conventions |  | 2. Notational Conventions |
| The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", |  | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", |
| "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this |  | "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this |
| 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. |
| skipping to change at page 4, line 6 |  | skipping to change at page 4, line 10 |
| [RFC2616], and explicitly includes the following rules from it: |  | [RFC2616], and explicitly includes the following rules from it: |
| quoted-string, token, SP (space). Additionally, the following rules |  | quoted-string, token, SP (space). Additionally, the following rules |
| are included from [RFC3986]: URI and URI-Reference, and from |  | are included from [RFC3986]: URI and URI-Reference, and from |
| [RFC4288]: type-name. |  | [RFC4288]: type-name. |
| 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 IRIs [RFC3987], and is comprised of: |
| o A context IRI, and |  | o A context IRI, and |
| o A link relation type (Section 4), and |  | o a link relation type (Section 4), and |
| o A target IRI. |  | o a target IRI, and |
|  |  | o optionally, target attributes (e.g., hinting the media type |
|  |  | returned by the target URI). |
| 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)." |  | {relation type} resource at {target IRI}, which has {target |
|  |  | 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 common protocols (such as HTTP) do not support |  | [RFC3986], because common 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 in serialisations that do not support IRIs (e.g., the Link |  | URI (see [RFC3987], Section 3.1) in serialisations that do not |
| 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 from and to a particular IRI, and |
| multiple links of different types between two given IRIs. |  | multiple links of different types between two given IRIs. Likewise, |
|  |  | the relative ordering of links in any particular serialisation, or |
|  |  | between serialisations (e.g., the Link header and in-content links) |
|  |  | is not specified or significant in this specification; applications |
|  |  | that wish to consider ordering significant MAY do so. |
| Additionally, this specification does not define a general syntax for |  | Target attributes are a set of key/value pairs. This specification |
|  |  | does not attempt to coordinate their names or use, but does provide |
|  |  | several common attributes for use in the Link HTTP header. |
|  |  | Finally, this specification does not define a general syntax for |
| expressing links, nor mandate a specific context for any given link; |  | expressing links, nor mandate a specific context for any given link; |
| it is expected that applications of links will specify both aspects. |  | it is expected that serialisations of links will specify both |
| One such application is communication of links through HTTP headers, |  | aspects. One such serialisation is communication of links through |
| specified in Section 5. |  | HTTP headers, specified in Section 5. |
| Such applications may further constrain or extend links (e.g., |  | Such serialisations may further constrain or extend links (e.g., |
| associating a media type hint). |  | associating additional target attributes like a media type hint). |
| 4. Link Relation Types |  | 4. Link Relation Types |
| A link relation type identifies the semantics of a link. For |  | A link relation type identifies the semantics of a link. For |
| example, a link with the relation type "copyright" indicates that the |  | example, a link with the relation type "copyright" indicates that the |
| resource identified by the target IRI is a statement of the copyright |  | resource identified by the target IRI is a statement of the copyright |
| terms applying to the current context IRI. |  | terms applying to the current context IRI. |
| Relation types are not to be confused with media types [RFC4288]; |  | Relation types are not to be confused with media types [RFC4288]; |
| they do not identify the format of the representation that results |  | they do not identify the format of the representation that results |
| when the link is dereferenced. Rather, they only describe how the |  | when the link is dereferenced. Rather, they only describe how the |
| current context is related to another resource. |  | current context is related to another resource. |
| As such, relation types are not format-specific, and MUST NOT specify |  | As such, relation types are not format-specific, and MUST NOT specify |
| a particular format or media type that they are to be used with. |  | a particular format or media type that they are to be used with. |
| Likewise, the context IRI for a given link is usually determined by |  | Likewise, the context IRI for a given link is usually determined by |
| the serialisation of the link (e.g., the Link header, a HTML |  | the serialisation of the link (e.g., the Link header, a HTML |
| document, etc.); a relation type SHOULD NOT specify the context IRI. |  | document, etc.); a relation type SHOULD NOT specify the context IRI. |
|  |  | Relation types SHOULD NOT infer any additional semantics based upon |
|  |  | the presence or absence of another link relation, or its own |
|  |  | cardinality of occurrence. An exception to this is the combination |
|  |  | of the "alternate" and "stylesheet" registered relation types, which |
|  |  | have special meaning in HTML4 for historical reasons. |
| Consuming implementations SHOULD ignore relation types that they do |  | Consuming implementations SHOULD ignore relation types that they do |
| not understand or have no need to process. |  | not understand or have no need to process. |
| There are two kinds of relation types; registered and extension. |  | There are two kinds of relation types; registered and extension. |
| 4.1. Registered Relation Types |  | 4.1. Registered Relation Types |
| Commonly-used relation types with a clear meaning that are shared |  | Commonly-used relation types with a clear meaning that are shared |
| across applications can be registered as tokens for convenience and |  | across applications can be registered as tokens for convenience and |
| to promote reuse. For example, "self" and "alternate" are registered |  | to promote reuse. For example, "self" and "alternate" are registered |
| skipping to change at page 5, line 24 |  | skipping to change at page 5, line 44 |
| This draft establishes an IANA registry of such relation types; see |  | This draft establishes an IANA registry of such relation types; see |
| Section 6.2. |  | Section 6.2. |
| Registered relation types MUST conform to the token rule, and SHOULD |  | Registered relation types MUST conform to the token rule, and SHOULD |
| conform to the sgml-name rule for compatibility with deployed |  | conform to the sgml-name rule for compatibility with deployed |
| implementations; |  | implementations; |
| sgml-name = ALPHA *( ALPHA | DIGIT | "." | "-" ) |  | sgml-name = ALPHA *( ALPHA | DIGIT | "." | "-" ) |
| Names that differ only in case from existing entries (e.g., "Foo" and |  | Names that differ only in case from existing entries (e.g., "Foo" and |
| "foo") MUST NOT be registered. |  | "foo") MUST NOT be registered. Registered relation types MUST be |
|  |  | compared in a case-insensitive fashion. |
| Registered relation types MUST be compared in a case-insensitive |  |  |
| fashion. |  |  |
| Although they are specified as tokens, applications wishing to |  | Although registered relation types are specified as tokens, |
| internally refer to an extension relation type using a URI MAY do so |  | applications wishing to internally refer to one using a URI MAY do so |
| by considering it relative to the base URI |  | by considering it relative to the base URI |
| "http://www.iana.org/assignments/relation/". However, the URI form |  | "http://www.iana.org/assignments/relation/". However, the URI form |
| of a registered relation type SHOULD NOT be serialised when an |  | of a registered relation type SHOULD NOT be serialised when an |
| application specifies the use of a relation type, because a consuming |  | application specifies the use of a relation type, because a consuming |
| implementation may not recognise it. |  | implementation may not recognise it. |
| 4.2. Extension Relation Types |  | 4.2. Extension Relation Types |
| Applications that don't merit a registered relation type may use an |  | Applications that don't merit a registered relation type may use an |
| extension relation type. An extension relation type is a URI |  | extension relation type, which is a URI [RFC3986] that uniquely |
| [RFC3986] that, when dereferenced, SHOULD yield a document describing |  | identifies the relation type. Although the URI MAY point to a |
| that relation type. |  | resource that contains a definition of the semantics of the relation |
|  |  | type, clients SHOULD NOT access that resource to avoid overburdening |
|  |  | its server. |
| Extension relation types MUST be compared in a case-sensitive |  | When extension relation types are compared, they MUST be compared as |
| fashion, character-by-character. |  | URIs in a case-sensitive fashion, character-by-character. |
|  |  | Note that while extension relation types are required to be URIs, but |
|  |  | a serialisation of links MAY specify that they are expressed in |
|  |  | another form, as long as they can be converted to URIs. |
| 5. The Link Header Field |  | 5. The Link Header Field |
| The Link entity-header field provides a means for conveying one or |  | The Link entity-header field provides a means for serialising one or |
| more links in HTTP headers. It is semantically equivalent to the |  | more links in HTTP headers. It is semantically equivalent to the |
| <LINK> element in HTML, as well as the atom:link feed-level element |  | <LINK> element in HTML, as well as the atom:link feed-level element |
| in Atom [RFC4287]. |  | in Atom [RFC4287]. |
| Link = "Link" ":" #link-value |  | Link = "Link" ":" #link-value |
| link-value = "<" URI-Reference ">" *( ";" link-param ) ) |  | link-value = "<" URI-Reference ">" *( ";" link-param ) |
| link-param = ( ( "rel" "=" relation-types ) |  | link-param = ( ( "rel" "=" relation-types ) |
| | ( "rev" "=" relation-types ) |  | | ( "rev" "=" relation-types ) |
| | ( "type" "=" type-name ) |  | | ( "type" "=" type-name ) |
| | ( "title" "=" quoted-string ) |  | | ( "title" "=" quoted-string ) |
| | ( "title*" "=" enc2231-string ) |  | | ( "title*" "=" enc2231-string ) |
| | ( "anchor" "=" <"> URI-Reference <"> ) |  | | ( "anchor" "=" <"> URI-Reference <"> ) |
| | ( link-extension ) ) |  | | ( link-extension ) ) |
| link-extension = token [ "=" ( token | quoted-string ) ] |  | link-extension = token [ "=" ( token | quoted-string ) ] |
| enc2231-string = <extended-value, see <xref target="RFC2231"/>, |  | enc2231-string = <extended-value, see [RFC2231], Section 7> |
| Section 7> |  |  |
| relation-types = relation-type | |  | relation-types = relation-type | |
| <"> relation-type *( SP relation-type ) <"> |  | <"> relation-type *( SP relation-type ) <"> |
| relation-type = reg-relation-type | ext-relation-type |  | relation-type = reg-relation-type | ext-relation-type |
| reg-relation-type = token |  | reg-relation-type = token |
| ext-relation-type = URI |  | ext-relation-type = URI |
| 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. |  |  |
| Each link-value conveys one target IRI as a URI-Reference (after |  | Each link-value conveys one target IRI as a URI-Reference (after |
| conversion, if necessary) inside angle brackets ("<>"). If the URI- |  | conversion to one, if necessary) inside angle brackets ("<>"). If |
| Reference is relative, it MUST be resolved as per [RFC3986]. Note |  | the URI-Reference is relative, it MUST be resolved as per [RFC3986], |
| that any base IRI from the body's content is not applied. |  | Section 5. Note that any base IRI from the body's content is not |
|  |  | applied. |
| By default, the context of a link conveyed in the Link header field |  | By default, the context of a link conveyed in the Link header field |
| is the IRI associated with the representation it occurs in. When |  | is the IRI of the requested resource. When present, the anchor |
| present, the anchor parameter overrides this with another URI, such |  | parameter overrides this with another URI, such as a fragment of this |
| as a fragment of this resource, or a third resource (i.e., when the |  | resource, or a third resource (i.e., when the anchor value is an |
| anchor value is an absolute URI). |  | absolute URI). If the anchor parameter's value is a relative URI, it |
|  |  | MUST be resolved as per [RFC3986], Section 5. Note that any base URI |
|  |  | from the body's content is not applied. |
| Normally, the relation type of a link is conveyed in the "rel" |  | Normally, the relation type of a link is conveyed in the "rel" |
| parameter's value. The "rev" parameter has also been used for this |  | parameter's value. The "rev" parameter has also been used for this |
| purpose historically by some formats, and is included here for |  | purpose historically by some formats, and is included here for |
| compatibility with those uses, but its use is not encouraged nor |  | compatibility with those uses, but its use is not encouraged nor |
| defined by this specification. |  | defined by this specification. |
| 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 (","). |  | or comma (","). |
| The title parameter is used to label the destination of a link such |  | The "title", "title*" and any link-extension link-params are |
|  |  | considered to be the target parameters for the link. |
|  |  | The "title" parameter is used to label the destination of a link such |
| that it can be used as a human-readable identifier (e.g. a menu |  | that it can be used as a human-readable identifier (e.g. a menu |
| entry). The title* parameter MAY be used to instead to encode this |  | entry). Alternately, the "title*" parameter MAY be used encode this |
| label in an alternate character set, and/or contain language |  | label in a different character set, and/or contain language |
| information as per [RFC2231]. When using the enc2231-string syntax, |  | information as per [RFC2231]. When using the enc2231-string syntax, |
| producers MUST NOT use a charset value other than 'ISO-8859-1' or |  | producers MUST NOT use a charset value other than 'ISO-8859-1' or |
| 'UTF-8'. |  | 'UTF-8'. |
|  |  | 5.1. Examples |
|  |  | NOTE: Non-ASCII characters used in prose for examples are encoded |
|  |  | using the format "Backslash-U with Delimiters", defined in Section |
|  |  | 5.1 of [RFC5137]. |
|  |  | 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. |
|  |  | The example below shows an instance of the Link header encoding |
|  |  | multiple links, and also the use of RFC 2231 encoding to encode both |
|  |  | non-ASCII characters and language information. |
|  |  | Link: </TheBook/chapter2>; |
|  |  | rel="previous"; title*=UTF-8'de'letztes%20Kapitel", |
|  |  | </TheBook/chapter4>; |
|  |  | rel="next"; title*=UTF-8'de'n%c3%a4chstes%20Kapitel" |
|  |  | Here, the second link has a title encoded in UTF-8, uses the German |
|  |  | language ("de"), and contains the Unicode code point \u'00E4' ("LATIN |
|  |  | SMALL LETTER A WITH DIAERESIS"). |
| Note that link-values may convey multiple links between the same |  | Note that link-values may convey multiple links between the same |
| target and context IRIs; for example |  | target and context IRIs; for example: |
| Link: <http://example.org/>; rel=index; |  | Link: <http://example.org/>; rel=index; |
| 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 |
| types "index" and "start", and the extension relation type |  | types "index" and "start", and the extension relation type |
| "http://example.net/relation/other". |  | "http://example.net/relation/other". |
| 6. IANA Considerations |  | 6. IANA Considerations |
| skipping to change at page 8, line 7 |  | skipping to change at page 9, line 8 |
| The requirements for registered relation types are described in |  | The requirements for registered relation types are described in |
| Section 4.1. |  | Section 4.1. |
| Relation types may be registered on the advice of a Designated Expert |  | Relation types may be 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, typically published in an RFC or Open Standard (in the sense |  | below, typically published in an RFC or Open Standard (in the sense |
| described by [RFC2026], section 7). However, to allow for the |  | described by [RFC2026], Section 7). However, to allow for the |
| allocation of values prior to publication, the Designated Expert may |  | allocation of values prior to publication, the Designated Expert may |
| approve registration once they are satisfied that an RFC (or other |  | approve registration once they are satisfied that an RFC (or other |
| Open Standard) will be published. |  | Open Standard) will be published. |
| The registration template is: |  | The registration template is: |
| o Relation Name: |  | o Relation Name: |
| o Description: |  | o Description: |
| o Reference: |  | o Reference: |
| skipping to change at page 9, line 35 |  | skipping to change at page 10, line 37 |
| 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: <http://www.iana.org/assignments/link-relations/first> |  | o Reference: [this document] |
| 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, |
| links to other sources information, etc.) |  | links to other sources information, etc.) |
| o Reference: [W3C.REC-html401-19991224] |  | o Reference: [W3C.REC-html401-19991224] |
| skipping to change at page 9, line 48 |  | skipping to change at page 11, line 4 |
| 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, |
| links to other sources information, etc.) |  | links to other sources information, etc.) |
| o Reference: [W3C.REC-html401-19991224] |  | o Reference: [W3C.REC-html401-19991224] |
| 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: <http://www.iana.org/assignments/link-relations/last> |  | o Reference: [this document] |
| o Relation Name: license |  | o Relation Name: license |
| o Description: Refers to a license associated with the link's |  | o Description: Refers to a license associated with the link's |
| context. |  | context. |
| o Reference: [RFC4946] |  | o Reference: [RFC4946] |
| o Relation Name: next |  | o Relation Name: next |
| 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: |  | o Reference: [this document] |
| <http://www.iana.org/assignments/link-relations/payment> |  |  |
| o Relation Name: prev |  | o Relation Name: prev |
| o Description: Refers to the previous resource in an ordered series |  | o Description: Refers to the previous resource in an ordered series |
| of resources. Synonym for "previous". |  | of resources. Synonym for "previous". |
| o Reference: [W3C.REC-html401-19991224] |  | o Reference: [W3C.REC-html401-19991224] |
| o Relation Name: previous |  | o Relation Name: previous |
| o Description: Refers to the previous resource in an ordered series |  | o Description: Refers to the previous resource in an ordered series |
| of resources. Synonym for "prev". |  | of resources. Synonym for "prev". |
| o Reference: [W3C.REC-html401-19991224] |  | o Reference: [W3C.REC-html401-19991224] |
| skipping to change at page 11, line 45 |  | skipping to change at page 12, line 48 |
| it. |  | it. |
| 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. |
| 8. Internationalisation Considerations |  | 8. Internationalisation Considerations |
| Target IRIs may need to be converted to URIs in order to serialise |  | Target IRIs may need to be converted to URIs in order to express them |
| them in applications that do not support IRIs. This includes the |  | in serialisations that do not support IRIs. This includes the Link |
| Link HTTP header. |  | HTTP header. |
| Similarly, the anchor parameter of the Link header does not support |  | Similarly, the anchor parameter of the Link header does not support |
| IRIs, and therefore IRIs must be converted to URIs before inclusion |  | IRIs, and therefore IRIs must be converted to URIs before inclusion |
| 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 |
| skipping to change at page 13, line 20 |  | skipping to change at page 14, line 25 |
| September 2006. |  | September 2006. |
| [RFC4946] Snell, J., "Atom License Extension", RFC 4946, July 2007. |  | [RFC4946] Snell, J., "Atom License Extension", RFC 4946, July 2007. |
| [RFC5005] Nottingham, M., "Feed Paging and Archiving", RFC 5005, |  | [RFC5005] Nottingham, M., "Feed Paging and Archiving", RFC 5005, |
| September 2007. |  | September 2007. |
| [RFC5023] Gregorio, J. and B. de hOra, "The Atom Publishing |  | [RFC5023] Gregorio, J. and B. de hOra, "The Atom Publishing |
| Protocol", RFC 5023, October 2007. |  | Protocol", RFC 5023, October 2007. |
|  |  | [RFC5137] Klensin, J., "ASCII Escaping of Unicode Characters", |
|  |  | BCP 137, RFC 5137, February 2008. |
| [W3C.REC-html401-19991224] |  | [W3C.REC-html401-19991224] |
| Raggett, D., Hors, A., and I. Jacobs, "HTML 4.01 |  | Raggett, D., Hors, A., and I. Jacobs, "HTML 4.01 |
| Specification", W3C REC REC-html401-19991224, |  | Specification", W3C REC REC-html401-19991224, |
| December 1999. |  | December 1999. |
| Appendix A. Notes on Using the Link Header with HTML4 |  | Appendix A. Notes on Using the Link Header with HTML4 |
| 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 |
| both the relation type, as in the Link header. The context of the |  | the relation type, as in the Link header. The context of the link is |
| link is the URI associated with the entire HTML document. |  | the URI associated with the entire HTML document. |
| HTML4 also has a "rev" parameter for links that allows a link's |  | HTML4 also has a "rev" parameter for links that allows a link's |
| relation to be reversed. The Link header has a "rev" parameter to |  | relation to be reversed. The Link header has a "rev" parameter to |
| allow the expression of these links in HTTP headers, but its use is |  | allow the expression of these links in HTTP headers, but its use is |
| not encouraged, due to the confusion this mechanism causes as well as |  | not encouraged, due to the confusion this mechanism causes as well as |
| conflicting interpretations among HTML versions. |  | conflicting interpretations among HTML versions. |
| All of the link relations defined by HTML4 have been included in the |  | All of the link relations defined by HTML4 have been included in the |
| link relation registry, so they can be used without modification. |  | link relation registry, so they can be used without modification. |
| However, extension link relations work differently in HTML4 and the |  | However, extension link relations work differently in HTML4 and the |
| Link header; the former uses a document-wide "profile" URI to scope |  | Link header; the former uses a document-wide "profile" URI to scope |
| the relations, while the latter allows the use of full URIs on |  | the relations, while the latter allows the use of full URIs on |
| individual relations. |  | individual relations. |
| Therefore, when using the profile mechanism in HTML4, it is necessary |  | Therefore, when using the profile mechanism in HTML4, it is necessary |
| to map the profiled link relations to URIs when expressed in Link |  | to map the profiled link relations to URIs when expressed in Link |
| headers. For example, in HTML: |  | headers. For example, in HTML: |
| <html> |  | <html> |
| skipping to change at page 14, line 31 |  | skipping to change at page 15, line 39 |
| relation types that are not URIs are (perhaps inevitably) common. |  | relation types that are not URIs are (perhaps inevitably) common. |
| Consuming HTML implementations should not consider such unregistered |  | Consuming HTML implementations should not consider such unregistered |
| short links to be errors, but rather relation types with a local |  | short links to be errors, but rather relation types with a local |
| scope (i.e., their meaning is specific and perhaps private to that |  | scope (i.e., their meaning is specific and perhaps private to that |
| document). |  | document). |
| 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 |
|  |  | "alternate" and "stylesheet" relations coincide in the same link. |
|  |  | Such links should be serialised in the Link header using a single |
|  |  | list of relation-types (e.g., rel="alternate stylesheet") to preserve |
|  |  | this relationship. |
| Appendix B. Notes on Using the Link Header with Atom |  | Appendix B. Notes on Using the Link Header with Atom |
| 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 candidates for transmission as a Link header. |  | feed-level links are candidates for transmission as a Link 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 15, line 14 |  | skipping to change at page 16, line 27 |
| that they are not mistaken for extension relation types. |  | that they are not mistaken for extension relation types. |
| Note also that while the Link header allows multiple relations to be |  | Note also that while the Link header allows multiple relations to be |
| associated with a single link, atom:link does not. In this case, a |  | associated with 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 may also be |  | explicitly mirrored in the Link header syntax, but they may also be |
| used as link-extensions. |  | used as link-extensions. |
| Appendix C. Acknowledgements |  | Appendix C. Defining New Link Serialisations |
|  |  | New serialisations of links (as defined by this specification) need |
|  |  | to address several issues, including: |
|  |  | o Specific syntax for each component of the link model described in |
|  |  | Section 3. |
|  |  | o What target attributes, if any, are defined by the serialisation. |
|  |  | o How to determine the context of the link. |
|  |  | o How to differentiate registered link relations from extension link |
|  |  | relations (if the latter are serialised as URIs, this is |
|  |  | relatively straightforward). |
|  |  | Appendix D. 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 RFC2068; credit for it belongs entirely to the authors of and |
| contributors to that document. The link relation registrations |  | contributors to that document. The link relation 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 draft, especially including |  | encouraged and gave feedback to this draft, especially including |
| Frank Ellermann, Roy Fielding and Julian Reschke. |  | Frank Ellermann, Roy Fielding and Julian Reschke. |
| Appendix D. Document history |  | Appendix E. Document history |
| [[ to be removed by the RFC editor before publication as an RFC. ]] |  | [[ to be removed by the RFC editor before publication as an RFC. ]] |
|  |  | -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. |
| -04 |  | -04 |
| o Defined context as a resource, rather than a representation. |  | o Defined context as a resource, rather than a representation. |
| o Removed concept of link directionality; relegated to a deprecated |  | o Removed concept of link directionality; relegated to a deprecated |
| Link header extension. |  | Link header extension. |
| o Relation types split into registered (non-URI) and extension |  | o Relation types split into registered (non-URI) and extension |
| (URI). |  | (URI). |
| o Changed wording around finding URIs for registered relation types. |  | o Changed wording around finding URIs for registered relation types. |
| o Changed target and context URIs to IRIs (but not extension |  | o Changed target and context URIs to IRIs (but not extension |
| relation types). |  | relation types). |
End of changes. 43 change blocks.
| 87 lines changed or deleted |  | 186 lines changed or added |
This html diff was produced by rfcdiff 1.34. The latest version is available from http://tools.ietf.org/tools/rfcdiff/