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