| draft-nottingham-http-link-header-03.txt |  | draft-nottingham-http-link-header-04.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: June 4, 2009 |  | Expires: August 29, 2009 |
| Link Relations and HTTP Header Linking |  | Link Relations and HTTP Header Linking |
| draft-nottingham-http-link-header-03 |  | draft-nottingham-http-link-header-04 |
| Status of this Memo |  | Status of this Memo |
| By submitting this Internet-Draft, each author represents that any |  | This Internet-Draft is submitted to IETF in full conformance with the |
| applicable patent or other IPR claims of which he or she is aware |  | provisions of BCP 78 and BCP 79. This document may contain material |
| have been or will be disclosed, and any of which he or she becomes |  | from IETF Documents or IETF Contributions published or made publicly |
| aware will be disclosed, in accordance with Section 6 of BCP 79. |  | available before November 10, 2008. The person(s) controlling the |
|  |  | copyright in some of this material may not have granted the IETF |
|  |  | Trust the right to allow modifications of such material outside the |
|  |  | IETF Standards Process. Without obtaining an adequate license from |
|  |  | the person(s) controlling the copyright in such materials, this |
|  |  | document may not be modified outside the IETF Standards Process, and |
|  |  | derivative works of it may not be created outside the IETF Standards |
|  |  | Process, except to format it for publication as an RFC or to |
|  |  | translate it into languages other than English. |
| Internet-Drafts are working documents of the Internet Engineering |  | Internet-Drafts are working documents of the Internet Engineering |
| Task Force (IETF), its areas, and its working groups. Note that |  | Task Force (IETF), its areas, and its working groups. Note that |
| other groups may also distribute working documents as Internet- |  | other groups may also distribute working documents as Internet- |
| Drafts. |  | Drafts. |
| Internet-Drafts are draft documents valid for a maximum of six months |  | Internet-Drafts are draft documents valid for a maximum of six months |
| 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 June 4, 2009. |  | This Internet-Draft will expire on August 29, 2009. |
|  |  | Copyright Notice |
|  |  | Copyright (c) 2009 IETF Trust and the persons identified as the |
|  |  | document authors. All rights reserved. |
|  |  | This document is subject to BCP 78 and the IETF Trust's Legal |
|  |  | Provisions Relating to IETF Documents in effect on the date of |
|  |  | publication of this document (http://trustee.ietf.org/license-info). |
|  |  | Please review these documents carefully, as they describe your rights |
|  |  | and restrictions with respect to this document. |
| 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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 |
| 4. Link Relation Types . . . . . . . . . . . . . . . . . . . . . 4 |  | 4. Link Relation Types . . . . . . . . . . . . . . . . . . . . . 4 |
| 5. The Link Header Field . . . . . . . . . . . . . . . . . . . . 5 |  | 5. The Link Header Field . . . . . . . . . . . . . . . . . . . . 5 |
| 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 |  | 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 |
| 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10 |  | 7. Security Considerations . . . . . . . . . . . . . . . . . . . 11 |
| 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 |  | 8. Internationalisation Considerations . . . . . . . . . . . . . 11 |
| 8.1. Normative References . . . . . . . . . . . . . . . . . . . 10 |  | 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 |
| 8.2. Informative References . . . . . . . . . . . . . . . . . . 11 |  | 9.1. Normative References . . . . . . . . . . . . . . . . . . . 12 |
| Appendix A. Notes on Using the Link Header with HTML . . . . . . 11 |  | 9.2. Informative References . . . . . . . . . . . . . . . . . . 12 |
| Appendix B. Notes on Using the Link Header with Atom . . . . . . 12 |  | Appendix A. Notes on Using the Link Header with HTML4 . . . . . . 13 |
| Appendix C. Acknowledgements . . . . . . . . . . . . . . . . . . 13 |  | Appendix B. Notes on Using the Link Header with Atom . . . . . . 14 |
| Appendix D. Document history . . . . . . . . . . . . . . . . . . 13 |  | Appendix C. Acknowledgements . . . . . . . . . . . . . . . . . . 15 |
| Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 14 |  | Appendix D. Document history . . . . . . . . . . . . . . . . . . 15 |
| Intellectual Property and Copyright Statements . . . . . . . . . . 15 |  | Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 16 |
| 1. Introduction |  | 1. Introduction |
| A means of indicating the relationships between documents 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 separate. However, links between resources need not be |  | similar, are separately specified. However, links between resources |
| format-specific; it can be useful to have typed links that are |  | need not be format-specific; it can be useful to have typed links |
| independent of the format, especially when a resource has |  | that are independent of the format, especially when a resource has |
| representations in multiple formats. |  | representations in multiple formats. |
| This document defines typed link relations, independent of the |  | To this end, this document defines a framework for typed links that |
| context they occur in. It does so by clarifying the status of the |  | isn't specific to a particular serialisation or context of use. It |
| link relation registry established by Atom, and registering in it the |  | does so by re-defining the link relation registry established by Atom |
| relations that are defined by HTML. |  | to have a broader scope, and adding to it the relations that are |
|  |  | 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 [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, several use cases for doing |  | implementation experience. Since then, it has been implemented in |
| so have surfaced. However, because it was removed, the status of the |  | some User-Agents (e.g., for stylesheets), and several additional use |
| Link header is unclear, leading some to consider minting new |  | cases have surfaced. Because it was removed, the status of the Link |
| application-specific HTTP headers instead of reusing it. This |  | header is unclear, leading some to consider minting new application- |
| document addresses this by re-specifying the Link header with updated |  | specific HTTP headers instead of reusing it. This document addresses |
| but backwards-compatible syntax. |  | this by re-specifying the Link header 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. |
| 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). 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 the context of this specification, a link is comprised of: |  | In this specification, a link is a typed connection between two |
|  |  | resources that are identified by IRIs [RFC3987], and is comprised of: |
| o A target URI ([RFC3986]), and |  | o A context IRI, and |
| o A context of use, and |  |  |
| o A link relation type (Section 4), and |  | o A link relation type (Section 4), and |
| o A link direction (outbound or inbound). |  | o A target IRI. |
| A link can be viewed as a statement of the form "(subject) has a |  | A link can be viewed as a statement of the form "(context IRI) has a |
| (relation type) at (object)", where for an outbound link the subject |  | (relation type) resource at (target IRI)." |
| is the context of use and the object is the resource identified by |  |  |
| the target URI, and for an inbound link the subject is the resource |  |  |
| identified by the target URI and the object is the context of use. |  |  |
| This specification does not define a general syntax for expressing |  | Note that in the common case, the context IRI will also be a URI |
| links, nor the specific context for a given link; it is expected that |  | [RFC3986], because HTTP requires that IRIs be converted to URIs |
| applications of link relations will specify both aspects. One such |  | before dereferencing. Likewise, the target IRI will be converted to |
| application is communication of links through HTTP headers, specified |  | a URI in serialisations that do not support IRIs (e.g., the Link |
| in Section 5. |  | header). |
|  |  | This specification does not place restrictions on the cardinality of |
|  |  | links; there can be multiple links from and to a particular IRI, and |
|  |  | multiple links of different types between two given IRIs. |
|  |  | Additionally, this specification does not define a general syntax for |
|  |  | expressing links, nor mandate a specific context for any given link; |
|  |  | it is expected that applications of links will specify both aspects. |
|  |  | One such application is communication of links through HTTP headers, |
|  |  | specified in Section 5. |
| Such applications may further constrain or extend links (e.g., |  | Such applications may further constrain or extend links (e.g., |
| associating a media type hint, only allowing links in one direction). |  | associating 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, an outbound link with the relation type "copyright" |  | example, a link with the relation type "copyright" indicates that the |
| indicates that the resource identified is a statement of the |  | resource identified by the target IRI is a statement of the copyright |
| copyright terms applying to the current context of the link. |  | 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, a relation type SHOULD NOT specify what its context of its |  | Likewise, the context IRI for a given link is usually determined by |
| use is. |  | the serialisation of the link (e.g., the Link header, a HTML |
|  |  | document, etc.); a relation type SHOULD NOT specify the context IRI. |
| Relation types are URIs. Although specific applications of links may |  | Consuming implementations SHOULD ignore relation types that they do |
| specify the use of URI-References, they must also indicate how to |  | not understand or have no need to process. |
| resolve them to absolute URIs. |  |  |
| Although anyone may mint a URI to be used as a relation type, it is |  | There are two kinds of relation types; registered and extension. |
| expected that a few standard types will predominate. To facilitate |  |  |
| this, Section 6.2 establishes an IANA registry of relation types that |  | 4.1. Registered Relation Types |
| share a common base URI. |  |  |
|  |  | Commonly-used relation types with a clear meaning that are shared |
|  |  | across applications can be registered as tokens for convenience and |
|  |  | to promote reuse. For example, "self" and "alternate" are registered |
|  |  | relation types, because they are broadly useful. |
|  |  | This draft establishes an IANA registry of such relation types; see |
|  |  | Section 6.2. |
|  |  | Registered relation types MUST conform to the token rule, and SHOULD |
|  |  | conform to the sgml-name rule for compatibility with deployed |
|  |  | implementations; |
|  |  | sgml-name = ALPHA *( ALPHA | DIGIT | "." | "-" ) |
|  |  | Names that differ only in case from existing entries (e.g., "Foo" and |
|  |  | "foo") MUST NOT be registered. |
|  |  | Registered relation types MUST be compared in a case-insensitive |
|  |  | fashion. |
|  |  | Although they are specified as tokens, applications wishing to |
|  |  | internally refer to an extension relation type using a URI MAY do so |
|  |  | by considering it relative to the base URI |
|  |  | "http://www.iana.org/assignments/relation/". However, the URI form |
|  |  | of a registered relation type SHOULD NOT be serialised when an |
|  |  | application specifies the use of a relation type, because a consuming |
|  |  | implementation may not recognise it. |
|  |  | 4.2. Extension Relation Types |
|  |  | Applications that don't merit a registered relation type may use an |
|  |  | extension relation type. An extension relation type is a URI |
|  |  | [RFC3986] that, when dereferenced, SHOULD yield a document describing |
|  |  | that relation type. |
|  |  | Extension relation types MUST be compared in a case-sensitive |
|  |  | fashion, character-by-character. |
| 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 conveying 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-type ) |  | link-param = ( ( "rel" "=" relation-types ) |
| | ( "rev" "=" relation-type ) |  | | ( "rev" "=" relation-types ) |
| | ( "type" "=" type-name ) |  | | ( "type" "=" type-name ) |
| | ( "title" "=" quoted-string ) |  | | ( "title" "=" quoted-string ) |
|  |  | | ( "title*" "=" enc2231-string ) |
|  |  | | ( "anchor" "=" <"> URI-Reference <"> ) |
| | ( link-extension ) ) |  | | ( link-extension ) ) |
| link-extension = token [ "=" ( token | quoted-string ) ] |  | link-extension = token [ "=" ( token | quoted-string ) ] |
| relation-type = URI-Reference | |  | enc2231-string = <extended-value, see <xref target="RFC2231"/>, |
| <"> URI-Reference *( SP URI-Reference) <"> |  | Section 7> |
|  |  | relation-types = relation-type | |
|  |  | <"> relation-type *( SP relation-type ) <"> |
|  |  | relation-type = reg-relation-type | ext-relation-type |
|  |  | reg-relation-type = token |
|  |  | ext-relation-type = URI |
| For example: |  | For example: |
| Link: <http://example.com/TheBook/chapter2>; rel="previous"; |  | Link: <http://example.com/TheBook/chapter2>; rel="previous"; |
| title="previous chapter" |  | title="previous chapter" |
| indicates that chapter2 is previous to this resource in a logical |  | indicates that chapter2 is previous to this resource in a logical |
| navigation path. |  | navigation path. |
| Each link-value conveys one target URI inside angle brackets ("<>"). |  | Each link-value conveys one target IRI as a URI-Reference (after |
| If it is relative, it MUST be resolved as per [RFC3986]. Note that |  | conversion, if necessary) inside angle brackets ("<>"). If the URI- |
| because it is conveyed in a header, base URIs from content are not |  | Reference is relative, it MUST be resolved as per [RFC3986]. Note |
| applied to it. |  | that any base IRI from the body's content is not applied. |
| The context of links conveyed in the Link header field is the |  |  |
| representation that the header is part of. |  |  |
| Each link-value MUST have at least one "rel" or "rev" parameter whose |  | By default, the context of a link conveyed in the Link header field |
| value indicates the relation type. If the "rel" parameter is used, |  | is the IRI associated with the representation it occurs in. When |
| it indicates that the link's direction for that relation type is |  | present, the anchor parameter overrides this with another URI, such |
| outbound; if the "rev" parameter is used, the given relation type's |  | as a fragment of this resource, or a third resource (i.e., when the |
| direction is inbound. |  | anchor value is an absolute URI). |
| If the relation-type is a relative URI, its base URI MUST be |  | Normally, the relation type of a link is conveyed in the "rel" |
| considered to be "http://www.iana.org/assignments/relation/", and the |  | parameter's value. The "rev" parameter has also been used for this |
| corresponding value MUST be present in the link relation registry. |  | purpose historically by some formats, and is included here for |
|  |  | compatibility with those uses, but its use is not encouraged nor |
|  |  | defined by this specification. |
| Relation-types that include a semicolon (";") or comma (",") MUST be |  | Note that extension relation types are REQUIRED to be absolute URIs |
| quoted. |  | in Link headers, and MUST be quoted if they contain a semicolon (";") |
|  |  | or comma (","). |
| The title parameter MAY be used to label the destination of a link |  | The title parameter is used to label the destination of a link such |
| such that it can be used as identification within a human-readable |  | that it can be used as a human-readable identifier (e.g. a menu |
| menu. |  | entry). The title* parameter MAY be used to instead to encode this |
|  |  | label in an alternate character set, and/or contain language |
|  |  | information as per [RFC2231]. When using the enc2231-string syntax, |
|  |  | producers MUST NOT use a charset value other than 'ISO-8859-1' or |
|  |  | 'UTF-8'. |
| Note that link-values may contain multiple relations; for example |  | Note that link-values may convey multiple links between the same |
|  |  | target and context IRIs; for example |
| Link: <http://example.org/>; rel="index start"; |  | Link: <http://example.org/>; rel=index; |
| rel="http://example.net/relation/other"; |  | rel="start http://example.net/relation/other" |
| rev=copyright |  |  |
| Here, the link "http://example.org/" has outbound links of the types |  | Here, the link to "http://example.org/" has the registered relation |
| "http://www.iana.org/assignments/relation/index", |  | types "index" and "start", and the extension relation type |
| "http://www.iana.org/assignments/relation/start", and |  | "http://example.net/relation/other". |
| "http://example.net/relation/other", as well as an inbound link of |  |  |
| type "http://www.iana.org/assignments/relation/copyright". |  |  |
| 6. IANA Considerations |  | 6. IANA Considerations |
| 6.1. Link Header Registration |  | 6.1. Link 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 |
| skipping to change at page 6, line 42 |  | skipping to change at page 7, line 46 |
| Specification document(s): |  | Specification document(s): |
| [ this document ] |  | [ this document ] |
| 6.2. Link Relation Type Registry |  | 6.2. Link Relation Type Registry |
| This specification establishes the Link Relation Type Registry, |  | This specification establishes the Link Relation Type Registry, |
| located at <http://www.iana.org/assignments/relation/>, and updates |  | located at <http://www.iana.org/assignments/relation/>, and updates |
| Atom [RFC4287] to refer to it in place of the "Registry of Link |  | Atom [RFC4287] to refer to it in place of the "Registry of Link |
| Relations". |  | Relations". |
| The semantics of relation types is described in Section 4. This |  | The requirements for registered relation types are described in |
| registry is intended to contain widely-used, standard relation types |  | Section 4.1. |
| so that they may be used in "short form" (i.e., as a relative URI) in |  |  |
| applications that allow this. |  |  |
| Registered relation types have an implicit base URI of |  |  |
| <http://www.iana.org/assignments/relation/>, and their name SHOULD be |  |  |
| limited to the sgml-name rule for simplicity and backwards- |  |  |
| compatibility. |  |  |
| sgml-name = ALPHA *( ALPHA | DIGIT | "." | "-" ) |  |  |
| Names that differ only in case (e.g., "Foo" and "foo") MUST NOT be |  | Relation types may be registered on the advice of a Designated Expert |
| registered. |  | (appointed by the IESG or their delegate), with a Specification |
|  |  | Required (using terminology from [RFC5226]). |
| New relation types can be registered by IETF Review, as outlined in |  | Registration requests consist of the completed registration template |
| [RFC5226]. Specifications of new values should use the following |  | below, typically published in an RFC or Open Standard (in the sense |
| template: |  | described by [RFC2026], section 7). However, to allow for the |
|  |  | allocation of values prior to publication, the Designated Expert may |
|  |  | approve registration once they are satisfied that an RFC (or other |
|  |  | Open Standard) will be published. |
| o Relation Name: |  | o Relation Name: |
| o Description: |  | o Description: |
| o Reference: |  | o Reference: |
|  |  | Upon receiving a registration request (usually via IANA), the |
|  |  | Designated Expert should request review and comment from the apps- |
|  |  | discuss mailing list (or a successor designated by the APPS Area |
|  |  | Directors). Before a period of 30 days has passed, the Designated |
|  |  | Expert will either approve or deny the registration request, |
|  |  | communicating this decision both to the review list and to IANA. |
|  |  | Denials should include an explanation and, if applicable, suggestions |
|  |  | as to how to make the request successful. |
| 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. |
| o Reference: [W3C.REC-html401-19991224] |  | o Reference: [W3C.REC-html401-19991224] |
| o Relation Name: appendix |  | o Relation Name: appendix |
| o Description: Refers to an appendix. |  | o Description: Refers to an appendix. |
| o Reference: [W3C.REC-html401-19991224] |  | o Reference: [W3C.REC-html401-19991224] |
| skipping to change at page 7, line 44 |  | skipping to change at page 9, line 4 |
| o Reference: [W3C.REC-html401-19991224] |  | o Reference: [W3C.REC-html401-19991224] |
| o Relation Name: contents |  | o Relation Name: contents |
| o Description: Refers to a table of contents. |  | o Description: Refers to a table of contents. |
| o Reference: [W3C.REC-html401-19991224] |  | o Reference: [W3C.REC-html401-19991224] |
| o Relation Name: copyright |  | o Relation Name: copyright |
| o Description: Refers to a copyright statement that applies to the |  | o Description: Refers to a copyright statement that applies to the |
| link's context. |  | link's context. |
| o Reference: [W3C.REC-html401-19991224] |  | o Reference: [W3C.REC-html401-19991224] |
| o Relation Name: current |  | o Relation Name: current |
| o Description: Refers to a resource containing the most recent |  | o Description: Refers to a resource containing the most recent |
| item(s) in a collection of resources. |  | item(s) in a collection of resources. |
| o Reference: [RFC5005] |  | o Reference: [RFC5005] |
|  |  | o Relation Name: describedby |
|  |  | o Description: Refers to a resource providing information about the |
|  |  | link's context. |
|  |  | o Documentation: <http://www.w3.org/TR/powder-dr/> |
| o Relation Name: edit |  | o Relation Name: edit |
| o Description: Refers to a resource that can be used to edit the |  | o Description: Refers to a resource that can be used to edit the |
| link's context. |  | link's context. |
| o Reference: [RFC5023] |  | o Reference: [RFC5023] |
| o Relation Name: edit-media |  | o Relation Name: edit-media |
| o Description: Refers to a resource that can be used to edit media |  | o Description: Refers to a resource that can be used to edit media |
| associated with the link's context. |  | associated with the link's context. |
| 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: A URI 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: <http://www.iana.org/assignments/link-relations/first> |
| 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] |
| 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: A URI 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: <http://www.iana.org/assignments/link-relations/last> |
| 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. |
| skipping to change at page 10, line 25 |  | skipping to change at page 11, line 38 |
| o Reference: [RFC4287] |  | o Reference: [RFC4287] |
| 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. |  | 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. |  | otherwise using links gathered from HTTP headers. In particular, |
|  |  | Link headers that use the "anchor" parameter to associate a link's |
|  |  | context with another resource should be treated with due caution. |
| 8. References |  | 8. Internationalisation Considerations |
| 8.1. Normative References |  | Target IRIs may need to be converted to URIs in order to serialise |
|  |  | them in applications that do not support IRIs. This includes the |
|  |  | Link HTTP header. |
|  |  | Similarly, the anchor parameter of the Link header does not support |
|  |  | IRIs, and therefore IRIs must be converted to URIs before inclusion |
|  |  | there. |
|  |  | Relation types are defined as URIs, not IRIs, to aid in their |
|  |  | comparison. It is not expected that they will be displayed to end |
|  |  | users. |
|  |  | 9. References |
|  |  | 9.1. Normative References |
|  |  | [RFC2026] Bradner, S., "The Internet Standards Process -- Revision |
|  |  | 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. |
|  |  | [RFC2231] Freed, N. and K. Moore, "MIME Parameter Value and Encoded |
|  |  | Word Extensions: Character Sets, Languages, and |
|  |  | Continuations", RFC 2231, November 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. |
| [RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration |  | [RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration |
| Procedures for Message Header Fields", BCP 90, RFC 3864, |  | Procedures for Message Header Fields", BCP 90, RFC 3864, |
| September 2004. |  | September 2004. |
| [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform |  | [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform |
| Resource Identifier (URI): Generic Syntax", STD 66, |  | Resource Identifier (URI): Generic Syntax", STD 66, |
| RFC 3986, January 2005. |  | RFC 3986, January 2005. |
|  |  | [RFC3987] Duerst, M. and M. Suignard, "Internationalized Resource |
|  |  | Identifiers (IRIs)", RFC 3987, January 2005. |
| [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. |
| 8.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. |
| [RFC4287] Nottingham, M. and R. Sayre, "The Atom Syndication |  | [RFC4287] Nottingham, M. and R. Sayre, "The Atom Syndication |
| Format", RFC 4287, December 2005. |  | Format", RFC 4287, December 2005. |
| [RFC4685] Snell, J., "Atom Threading Extensions", RFC 4685, |  | [RFC4685] Snell, J., "Atom Threading Extensions", RFC 4685, |
| September 2006. |  | September 2006. |
| skipping to change at page 11, line 32 |  | skipping to change at page 13, line 22 |
| 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. |
| [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 HTML |  | 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" and rev" |  | by using the "href" attribute for the target URI, and "rel" to convey |
| to convey both the relation type and its direction, as in the Link |  | both the relation type, as in the Link header. The context of the |
| header. The context of the link is generally the entire HTML |  | link is the URI associated with the entire HTML document. |
| document. |  |  |
|  |  | 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 |
|  |  | 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 |
|  |  | 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> |
| <head profile="http://example.com/profile1/"> |  | <head profile="http://example.com/profile1/"> |
| <link rel="foo" href="/foo"> |  | <link rel="foo" href="/bar"> |
| </head> |  | </head> |
| [...] |  | [...] |
| could be represented as a header like this; |  | could be represented as a header like this; |
| Link: </foo>; rel="http://example.com/profile1/foo" |  | Link: </bar>; rel="http://example.com/profile1/foo" |
| Profile authors should note this when creating profile URIs; it may |  | Profile authors should note this when creating profile URIs; it may |
| be desirable to use URIs that end in a delimiter (e.g., "/" or "#"), |  | be desirable to use URIs that end in a delimiter (e.g., "/" or "#"), |
| to make extracting the specific relation in use easier. |  | to make extracting the specific relation in use easier. |
| HTML defines link relation values as case-insensitive, while the Link |  | Surveys of existing HTML content have shown that unregistered link |
| header's syntax does not. Therefore, it is important to case- |  | relation types that are not URIs are (perhaps inevitably) common. |
| normalise relation values in HTML before comparing or converting them |  | Consuming HTML implementations should not consider such unregistered |
| to Link headers. |  | short links to be errors, but rather relation types with a local |
|  |  | scope (i.e., their meaning is specific and perhaps private to that |
|  |  | document). |
| HTML also defines several attributes on links that are not explicitly |  | HTML4 also defines several attributes on links that are not |
| defined by the Link header. Although most of these are believed to |  | explicitly defined by the Link header. These attributes can be |
| be defunct, they can be used as link-extensions. |  | serialised as link-extensions to maintain fidelity. |
| 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 URI 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 or an entry, depending on where it appears; generally, feed- |  | feed IRI or an entry ID, depending on where it appears; generally, |
| level links are candidates for transmission as a Link header. Since |  | feed-level links are candidates for transmission as a Link header. |
| atom:link only specifies "rel", only outbound links are allowed by |  |  |
| non-extended Atom syntax. |  |  |
| 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 IRIs (if used) to URIs. Additionally, since the base URI for |  | convert target IRIs (if used) to URIs. |
| link relations in Link headers is fixed, extension relation types |  |  |
| (i.e,. those not in the registry) must be represented as absolute |  | Atom defines extension relation types in terms of IRIs. This |
| URIs. |  | specification defines them as URIs, to aid in their comparison. |
|  |  | Atom allows registered link relation types to be serialised as |
|  |  | absolute URIs, because a base URI is defined for the registry. Such |
|  |  | relation types SHOULD be converted to the appropriate registered form |
|  |  | (e.g., "http://www.iana.org/assignments/relation/self" to "self") so |
|  |  | that they are not mistaken for extension relation types. |
| 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. 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 and Julian Reschke. |  | Frank Ellermann, Roy Fielding and Julian Reschke. |
| Appendix D. Document history |  | Appendix D. 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. ]] |
| -03 |  | -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 Inverted focus from Link headers to link relations. |
| o Specified was a link relation type is. |  | o Specified was a link relation type is. |
| o Based on discussion, re-added 'rev'. |  | o Based on discussion, re-added 'rev'. |
| o Changed IESG Approval to IETF Consensus for relation registrations |  | o Changed IESG Approval to IETF Consensus for relation registrations |
| (i.e., require a document). |  | (i.e., require a document). |
| o Updated RFC2434 reference to RFC5226. |  | o Updated RFC2434 reference to RFC5226. |
| o Registered relations SHOULD conform to sgml-name. |  | o Registered relations SHOULD conform to sgml-name. |
| o Cautioned against confusing relation types with media types. |  | o Cautioned against confusing relation types with media types. |
| -02 |  | -02 |
| skipping to change at page 15, line 4 |  | skipping to change at line 738 |
| -00 |  | -00 |
| o Initial draft; normative text lifted from RFC2068. |  | 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/ |
| Full Copyright Statement |  |  |
| Copyright (C) The IETF Trust (2008). |  |  |
| This document is subject to the rights, licenses and restrictions |  |  |
| contained in BCP 78, and except as set forth therein, the authors |  |  |
| retain all their rights. |  |  |
| This document and the information contained herein are provided on an |  |  |
| "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS |  |  |
| OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND |  |  |
| THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS |  |  |
| OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF |  |  |
| THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED |  |  |
| WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. |  |  |
| Intellectual Property |  |  |
| The IETF takes no position regarding the validity or scope of any |  |  |
| Intellectual Property Rights or other rights that might be claimed to |  |  |
| pertain to the implementation or use of the technology described in |  |  |
| this document or the extent to which any license under such rights |  |  |
| might or might not be available; nor does it represent that it has |  |  |
| made any independent effort to identify any such rights. Information |  |  |
| on the procedures with respect to rights in RFC documents can be |  |  |
| found in BCP 78 and BCP 79. |  |  |
| Copies of IPR disclosures made to the IETF Secretariat and any |  |  |
| assurances of licenses to be made available, or the result of an |  |  |
| attempt made to obtain a general license or permission for the use of |  |  |
| such proprietary rights by implementers or users of this |  |  |
| specification can be obtained from the IETF on-line IPR repository at |  |  |
| http://www.ietf.org/ipr. |  |  |
| The IETF invites any interested party to bring to its attention any |  |  |
| copyrights, patents or patent applications, or other proprietary |  |  |
| rights that may cover technology that may be required to implement |  |  |
| this standard. Please address the information to the IETF at |  |  |
| ietf-ipr@ietf.org. |  |  |
End of changes. 57 change blocks.
| 141 lines changed or deleted |  | 281 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/