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/