mnot@pobox.com http://www.mnot.net/

This specification clarifies the status of the Link HTTP header and introduces the complimentary Profile and Link-Template HTTP headers.

A means of indicating the relationships between documents on the Web has been available for some time in HTML, and was considered as a HTTP header in , but removed from , due to a lack of implementation experience. There have since surfaced many cases where a means of including this information in HTTP headers has proved useful. However, because it was removed, the status of the Link header is unclear, leading some to consider minting new application-specific HTTP headers instead of reusing it. Additionally, the complementary "profile" mechanism -- which is often used to disambiguate link relationship types -- is not available as a HTTP header. This specification seeks to address these shortcomings. It also introduces a new header, Link-Template, that allows the structure of links to be described.

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, , as scoped to those conformance targets. This specification uses the Augmented Backus-Naur Form (ABNF) notation of , and explicitly includes the following rules from it: quoted-string, token, SP (space), ALPHA (letters), DIGIT (decimal digit). Additionally, the following rules are included from : URI-Reference, reserved, unreserved.

The Link entity-header field provides a means for describing a relationship between two resources, generally between the requested resource and some other resource. An entity MAY include multiple Link values. Links at the metainformation level typically indicate relationships like hierarchical structure and navigation paths. The Link field is semantically equivalent to the <LINK> element in HTML.

" *( ";" link-param ) ) link-param = ( ( "rel" "=" relationship ) | ( "rev" "=" relationship ) | ( "title" "=" quoted-string ) | ( "anchor" "=" <"> URI-Reference <"> ) | ( link-extension ) ) link-extension = token [ "=" ( token | quoted-string ) ] relationship = sgml-name | ( <"> sgml-name *( SP sgml-name) <"> ) sgml-name = ALPHA *( ALPHA | DIGIT | "." | "-" ) ]]>

Relationship values are case-insensitive and MAY be extended within the constraints of the sgml-name syntax. The title parameter MAY be used to label the destination of a link such that it can be used as identification within a human-readable menu. The anchor parameter MAY be used to indicate a source anchor other than the entire current resource, such as a fragment of this resource or a third resource. Examples of usage include:

; rel="Previous" Link: ; rev="Made"; title="Tim Berners-Lee" ]]>

The first example indicates that chapter2 is previous to this resource in a logical navigation path. The second indicates that the person responsible for making the resource available is identified by the given e-mail address.

The Profile entity-header field provides a means to indicate the meta data profile of the entity. Commonly, it is used to disambiguate the meaning of relationships in links. Note that this URI MAY be used as either an identifier (e.g., to uniquely identify links, without dereferencing the URI), or as a link that is intended to be dereferenced. The Profile field is semantically equivalent to the profile attribute of the HEAD element in HTML . Note, however, that its use is not limited to HTML entities.

") ]]>

For example:

Profile: , ]]>

The Link-Template entity-header field provides a means for describing the structure of a link between two resources, so that new links can be generated. It does so through by allowing brace ("{}") -delimited strings to be interposed throughout a URI reference. These correspond to variables which, after being replaced with content in a relation-specified manner, are semantically equivalent to the corresponding Link header. For example,

; rel="home" ]]>

This link indicates that the "home" link relation can be constructed if the userid variable is known; if it were known to be "bob", this header would be considered equivalent to

; rel="home" ]]>

This specification does not define when or how template variables are interposed into link templates. Link relations that wish to allow templating SHOULD specify such details. This specification does not define the correct behaviour in the face of a conflict between a Link-Template header and a Link header with the same relation. Link relations allowing templating SHOULD specify their relative precedence. Applications SHOULD NOT use link relations that do not explicitly allow such templating in the Link-Template header.

" *( ";" link-param ) ) template = *( uri-char | template-var ) template-var = "{" 1*( uri-char ) "}" uri-char = ( reserved | unreserved ) ]]>

This specification requires registration of two Message Header Fields for HTTP . Note that "Link" is already present in the registry; this registration only updates its specification document.

Header field: Link Applicable protocol: http Status: standard Author/change controller: IETF (iesg@ietf.org) Internet Engineering Task Force Specification document(s): [ this document ]

Header field: Profile Applicable protocol: http Status: standard Author/change controller: IETF (iesg@ietf.org) Internet Engineering Task Force Specification document(s): [ this document ]

Header field: Link-Template Applicable protocol: http Status: standard Author/change controller: IETF (iesg@ietf.org) Internet Engineering Task Force Specification document(s): [ this document ]

The content of both the Link and Profile headers are not secure, private or integrity-guaranteed, and due caution should be excercised when using them. Applications that take advantage of these mechanisms should consider the attack vectors opened by automatically following, trusting, or otherwise using links gathered from HTTP headers.

Harvard University

1350 Mass. Ave. Cambridge MA 02138 - +1 617 495 3864 sob@harvard.edu

General keyword In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. Authors who follow these guidelines should incorporate this phrase near the beginning of their document: The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119. Note that the force of these words is modified by the requirement level of the document in which they are used. World Wide Web Consortium

Massachusetts Institute of Technology 77 Massachusetts Avenue Cambridge MA 02139 USA +1-617-253-5702 +1-617-258-5999 timbl@w3.org http://www.w3.org/People/Berners-Lee/

Day Software

5251 California Ave., Suite 110 Irvine CA 92617 USA +1-949-679-2960 +1-949-679-2972 fielding@gbiv.com http://roy.gbiv.com/

Adobe Systems Incorporated

345 Park Ave San Jose CA 95110 USA +1-408-536-3024 LMM@acm.org http://larry.masinter.net/

Applications uniform resource identifier URI URL URN WWW resource A Uniform Resource Identifier (URI) is a compact sequence of characters that identifies an abstract or physical resource. This specification defines the generic URI syntax and a process for resolving URI references that might be in relative form, along with guidelines and security considerations for the use of URIs on the Internet. The URI syntax defines a grammar that is a superset of all valid URIs, allowing an implementation to parse the common components of a URI reference without knowing the scheme-specific requirements of every possible identifier. This specification does not define a generative grammar for URIs; that task is performed by the individual specifications of each URI scheme. Department of Information and Computer Science

University of California, Irvine Irvine CA 92697-3425 +1(949)824-1715 fielding@ics.uci.edu

World Wide Web Consortium

MIT Laboratory for Computer Science, NE43-356 545 Technology Square Cambridge MA 02139 +1(617)258-8682 jg@w3.org

Compaq Computer Corporation

Western Research Laboratory 250 University Avenue Palo Alto CA 94305 mogul@wrl.dec.com

World Wide Web Consortium

MIT Laboratory for Computer Science, NE43-356 545 Technology Square Cambridge MA 02139 +1(617)258-8682 frystyk@w3.org

Xerox Corporation

MIT Laboratory for Computer Science, NE43-356 3333 Coyote Hill Road Palo Alto CA 94034 masinter@parc.xerox.com

Microsoft Corporation

1 Microsoft Way Redmond WA 98052 paulle@microsoft.com

World Wide Web Consortium

MIT Laboratory for Computer Science, NE43-356 545 Technology Square Cambridge MA 02139 +1(617)258-8682 timbl@w3.org

The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. It is a generic, stateless, protocol which can be used for many tasks beyond its use for hypertext, such as name servers and distributed object management systems, through extension of its request methods, error codes and headers . A feature of HTTP is the typing and negotiation of data representation, allowing systems to be built independently of the data being transferred. HTTP has been in use by the World-Wide Web global information initiative since 1990. This specification defines the protocol referred to as "HTTP/1.1", and is an update to RFC 2068 . This specification defines registration procedures for the message header fields used by Internet mail, HTTP, Netnews and other applications. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. University of California, Irvine, Department of Information and Computer Science

Irvine CA 92717-3425 US +1 714 824 4056 fielding@ics.uci.edu

MIT Laboratory for Computer Science

545 Technology Square Cambridge MA 02139 US +1 617 258 8682 jg@w3.org

Digital Equipment Corporation, Western Research Laboratory

250 University Avenue Palo Alto CA 94301 US mogul@wrl.dec.com

MIT Laboratory for Computer Science

545 Technology Square Cambridge MA 02139 US +1 617 258 8682 frystyk@w3.org

MIT Laboratory for Computer Science

545 Technology Square Cambridge MA 02139 US +1 617 258 8682 timbl@w3.org

The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. It is a generic, stateless, object-oriented protocol which can be used for many tasks, such as name servers and distributed object management systems, through extension of its request methods. A feature of HTTP is the typing and negotiation of data representation, allowing systems to be built independently of the data being transferred. HTTP has been in use by the World-Wide Web global information initiative since 1990. This specification defines the protocol referred to as "HTTP/1.1".

This specification lifts the definition of the Link header from RFC2068; credit for it belongs entirely to the authors of and contributors to that document. The semantics and much of the syntax of the Profile header was defined by HTML 4.01; credit for them belongs to the authors of and contributors to that document. Joe Gregorio, Marc Hadley and David Orchard contributed to the design of the Link-Template mechanism.