draft-nottingham-http-link-header-10.txt		draft-nottingham-http-link-header-09.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: November 6, 2010		Expires: October 4, 2010
	Web Linking		Web Linking
	draft-nottingham-http-link-header-10		draft-nottingham-http-link-header-09
	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		Status of this Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted in full conformance with the
	skipping to change at page 1, line 33		skipping to change at page 1, line 33
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at http://datatracker.ietf.org/drafts/current/.		Drafts is at http://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on November 6, 2010.		This Internet-Draft will expire on October 4, 2010.
	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 36		skipping to change at page 2, line 36
	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.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 . . . . . . . . . . . . . 17
	9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18		9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
	9.1. Normative References . . . . . . . . . . . . . . . . . . . 18		9.1. Normative References . . . . . . . . . . . . . . . . . . . 18
	9.2. Informative References . . . . . . . . . . . . . . . . . . 19		9.2. Informative References . . . . . . . . . . . . . . . . . . 18
	Appendix A. Link Relation Registry Format . . . . . . . . . . . . 20		Appendix A. Link Relation Registry Format . . . . . . . . . . . . 20
	A.1. Relax NG Grammar . . . . . . . . . . . . . . . . . . . . . 21		A.1. Relax NG Grammar . . . . . . . . . . . . . . . . . . . . . 20
	A.2. Example . . . . . . . . . . . . . . . . . . . . . . . . . 22		A.2. Example . . . . . . . . . . . . . . . . . . . . . . . . . 21
	Appendix B. Notes on Using the Link Header with the HTML4		Appendix B. Notes on Using the Link Header with the HTML4
	Format . . . . . . . . . . . . . . . . . . . . . . . 22		Format . . . . . . . . . . . . . . . . . . . . . . . 21
	Appendix C. Notes on Using the Link Header with the Atom		Appendix C. Notes on Using the Link Header with the Atom
	Format . . . . . . . . . . . . . . . . . . . . . . . 23		Format . . . . . . . . . . . . . . . . . . . . . . . 22
	Appendix D. Acknowledgements . . . . . . . . . . . . . . . . . . 24		Appendix D. Acknowledgements . . . . . . . . . . . . . . . . . . 23
	Appendix E. Document history . . . . . . . . . . . . . . . . . . 24		Appendix E. Document history . . . . . . . . . . . . . . . . . . 23
	Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 28		Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 27
	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
	skipping to change at page 5, line 28		skipping to change at page 5, line 28
	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
	Well-defined relation types can be registered as tokens for		Well-defined relation types can be registered as tokens for
	convenience and/or to promote reuse by other applications. This		convenience and/or to promote reuse by other applications. This
	specification establishes an IANA registry of such relation types;		specification establishes an IANA registry of such relation types;
	see Section 6.2.		see Section 6.2.
	Registered relation type names MUST conform to the reg-rel-type rule,		Registered relation type names MUST conform to the reg-relation-type
	and MUST be compared character-by-character in a case-insensitive		rule, and MUST be compared character-by-character in a case-
	fashion. They SHOULD be appropriate to the specificity of the		insensitive fashion. They SHOULD be appropriate to the specificity
	relation type; i.e., if the semantics are highly specific to a		of the 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 which must be
	supported).		supported).
	skipping to change at page 7, line 11		skipping to change at page 7, line 11
	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 )
	| ( "anchor" "=" <"> URI-Reference <"> )		| ( "anchor" "=" <"> URI-Reference <"> )
	| ( "rev" "=" relation-types )		| ( "rev" "=" relation-types )
	| ( "hreflang" "=" Language-Tag )		| ( "hreflang" "=" Language-Tag )
	| ( "media" "=" ( MediaDesc | ( <"> MediaDesc <"> ) ) )		| ( "media" "=" ( MediaDesc | <"> MediaDesc <"> ) )
	| ( "title" "=" quoted-string )		| ( "title" "=" quoted-string )
	| ( "title*" "=" ext-value )		| ( "title*" "=" ext-value )
	| ( "type" "=" ( media-type | quoted-mt ) )		| ( "type" "=" ( media-type | quoted-media-type ) )
	| ( link-extension ) )		| ( link-extension ) )
	link-extension = ( parmname [ "=" ( ptoken | quoted-string ) ] )		link-extension = ( parmname [ "=" ( ptoken | quoted-string ) ] )
	| ( ext-name-star "=" ext-value )		| ( ext-name-star "=" ext-value )
	ext-name-star = parmname "*" ; reserved for RFC2231-profiled		ext-name-star = parmname "*" ; reserved for RFC2231-profiled
	; extensions. Whitespace NOT		; extensions. Whitespace NOT
	; allowed in between.		; allowed in between.
	ptoken = 1*ptokenchar		ptoken = 1*ptokenchar
	ptokenchar = "!" | "#" | "$" | "%" | "&" | "'" | "("		ptokenchar = "!" | "#" | "$" | "%" | "&" | "'" | "("
	| ")" | "*" | "+" | "-" | "." | "/" | DIGIT		| ")" | "*" | "+" | "-" | "." | "/" | DIGIT
	| ":" | "<" | "=" | ">" | "?" | "@" | ALPHA		| ":" | "<" | "=" | ">" | "?" | "@" | ALPHA
	| "[" | "]" | "^" | "_" | "`" | "{" | "|"		| "[" | "]" | "^" | "_" | "`" | "{" | "|"
	| "}" | "~"		| "}" | "~"
	media-type = type-name "/" subtype-name		media-type = type-name "/" subtype-name
	quoted-mt = <"> media-type <">		quoted-media-type = <"> media-type <">
	relation-types = relation-type		relation-types = relation-type |
	| <"> relation-type *( 1*SP relation-type ) <">		<"> relation-type *( 1*SP relation-type ) <">
	relation-type = reg-rel-type | ext-rel-type		relation-type = reg-relation-type | ext-relation-type
	reg-rel-type = LOALPHA *( LOALPHA | DIGIT | "." | "-" )		reg-relation-type = LOALPHA *( LOALPHA | DIGIT | "." | "-" )
	ext-rel-type = URI		ext-relation-type = URI
	5.1. Target IRI		5.1. Target IRI
	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 to one, if necessary; see [RFC3987], Section 3.1) inside		conversion to one, if necessary; see [RFC3987], Section 3.1) inside
	angle brackets ("<>"). If the URI-Reference is relative, parsers		angle brackets ("<>"). If the URI-Reference is relative, parsers
	MUST resolve it as per [RFC3986], Section 5. Note that any base IRI		MUST resolve it as per [RFC3986], Section 5. Note that any base IRI
	from the message's content is not applied.		from the message's content is not applied.
	5.2. Context IRI		5.2. Context IRI
	skipping to change at page 11, line 41		skipping to change at page 11, line 41
	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 [TBD]@ietf.org mailing
	list, marked clearly in the subject line (e.g,. "NEW RELATION		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. Registration requests that are undetermined for a period
			longer than 21 days can be brought to the IESG's attention (using the
	Decisions (or lack thereof) made by the Designated Expert can be		iesg@iesg.org mailing list) for resolution.
	first appealed to Application Area Directors (contactable using
	app-ads@tools.ietf.org email address or directly by looking up their
	email addresses on http://www.iesg.org/ website) and, if the
	appellant is not satisfied with the response, to the full IESG (using
	the iesg@iesg.org mailing list).
	When a registration request is successful, the Designated Expert(s)		When a registration request is successful, the Designated Expert(s)
	will update the registry XML file (using the format described in		will update the registry XML file (using the format described in
	Appendix A including the MIT license) and send it to the [TBD-2]@		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		ietf.org mailing list (which SHOULD NOT be centrally archived, so as
	to avoid load issues from automated agents, and only accept posts		to avoid load issues from automated agents, and only accept posts
	from the Designated Expert(s)), so that implementers interested in		from the Designated Expert(s)), so that implementers interested in
	receiving a machine-readable registry can do so. Simultaneously,		receiving a machine-readable registry can do so. Simultaneously,
	they will send a text (not XML) version of the registry to IANA for		they will send a text (not XML) version of the registry to IANA for
	publication.		publication.
	skipping to change at page 13, line 43		skipping to change at page 13, line 38
	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: 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/>
	pubsubhubbub.googlecode.com/svn/trunk/pubsubhubbub-core-0.3.html>		o Notes: this relation type was requested by Brett Slakin.
	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: [this document]
	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.,
	skipping to change at page 14, line 15		skipping to change at page 14, line 8
	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: [this document]
	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: [I-D.brown-versioning-link-relations]
	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: [this document]		o Reference: [this document]
	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.
	meant as a general way to facilitate acts of payment, and thus
	this specification makes no assumptions on the type of payment or
	transaction protocol. Examples may include a web page where
	donations are accepted or where goods and services are available
	for purchase. rel="payment" is not intended to initiate an
	automated transaction. In Atom documents, a link element with a
	rel="payment" attribute may exist at the feed/channel level and/or
	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/
	item containing a book review may include a rel="payment" link
	that points to the location where the book may be purchased
	through an online retailer.
	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: predecessor-version		o Relation Name: predecessor-version
	o Description: Points to a resource containing the predecessor		o Description: Points to a resource containing the predecessor
	version in the version history.		version in the version history.
	o Reference: [RFC5829]		o Reference: [I-D.brown-versioning-link-relations]
	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]
	o Relation Name: prev-archive		o Relation Name: prev-archive
	o Description: Refers to the immediately preceding archive resource.		o Description: Refers to the immediately preceding archive resource.
	o Reference: [RFC5005]		o Reference: [RFC5005]
	skipping to change at page 16, line 19		skipping to change at page 15, line 45
	o Reference: [W3C.REC-html401-19991224]		o Reference: [W3C.REC-html401-19991224]
	o Relation Name: subsection		o Relation Name: subsection
	o Description: Refers to a resource serving as a subsection in a		o Description: Refers to a resource serving as a subsection in a
	collection of resources.		collection of resources.
	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: [I-D.brown-versioning-link-relations]
	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: [this document]
	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: [I-D.brown-versioning-link-relations]
	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
	information in the link's context.		information in the link's context.
	o Reference: [RFC4287]		o Reference: [RFC4287]
	o Relation Name: working-copy		o Relation Name: working-copy
	o Description: Points to a working copy for this resource.		o Description: Points to a working copy for this resource.
	o Reference: [RFC5829]		o Reference: [I-D.brown-versioning-link-relations]
	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: [I-D.brown-versioning-link-relations]
	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
	skipping to change at page 17, line 48		skipping to change at page 17, line 28
	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.
	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.
	See [RFC3987] for security considerations relating to IRIs. See
	[RFC3986] for security considerations relating to URIs. See
	[RFC2616] for security considerations relating to HTTP headers.
	8. Internationalisation Considerations		8. Internationalisation Considerations
	Target IRIs may need to be converted to URIs in order to express them		Target IRIs may need to be converted to URIs in order to express them
	in serialisations that do not support IRIs. This includes the Link		in serialisations that do not support IRIs. This includes the 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
	9.1. Normative References		9.1. Normative References
	[I-D.reschke-rfc2231-in-http]		[I-D.reschke-rfc2231-in-http]
	Reschke, J., "Character Set and Language Encoding for		Reschke, J., "Application of RFC 2231 Encoding to
	Hypertext Transfer Protocol (HTTP) Header Field		Hypertext Transfer Protocol (HTTP) Header Fields",
	Parameters", draft-reschke-rfc2231-in-http-12 (work in		draft-reschke-rfc2231-in-http-11 (work in progress),
	progress), April 2010.		March 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 25		skipping to change at page 18, line 48
	[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.
	9.2. Informative References		9.2. Informative References
			[I-D.brown-versioning-link-relations]
			Brown, A., Clemm, G., and J. Reschke, "Link Relation Types
			for Simple Version Navigation between Web Resources",
			draft-brown-versioning-link-relations-07 (work in
			progress), January 2010.
	[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		[RFC4287] Nottingham, M. and R. Sayre, "The Atom Syndication
	HTTP/1.1", RFC 2817, May 2000.		Format", RFC 4287, December 2005.
	[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
	[RFC4287] Nottingham, M., Ed. and R. Sayre, Ed., "The Atom
	Syndication Format", RFC 4287, December 2005.
	[RFC4685] Snell, J., "Atom Threading Extensions", RFC 4685,		[RFC4685] Snell, J., "Atom Threading Extensions", RFC 4685,
	September 2006.		September 2006.
	[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.
	[RFC5829] Brown, A., Clemm, G., and J. Reschke, "Link Relation Types
	for Simple Version Navigation between Web Resources",
	RFC 5829, April 2010.
	[W3C.CR-css3-mediaqueries-20090915]		[W3C.CR-css3-mediaqueries-20090915]
	van Kesteren, A., Glazman, D., Lie, H., and T. Celik,		van Kesteren, A., Glazman, D., Lie, H., and T. Celik,
	"Media Queries", W3C Candidate Recommendation CR-css3-		"Media Queries", W3C Candidate Recommendation CR-css3-
	mediaqueries-20090915, September 2009,		mediaqueries-20090915, September 2009,
	<http://www.w3.org/TR/2009/		<http://www.w3.org/TR/2009/
	CR-css3-mediaqueries-20090915/>.		CR-css3-mediaqueries-20090915/>.
	Latest version available at		Latest version available at
	<http://www.w3.org/TR/css3-mediaqueries/>.		<http://www.w3.org/TR/css3-mediaqueries/>.
	skipping to change at page 24, line 41		skipping to change at page 23, line 41
	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		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. ]]
	-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		-09
	o Corrected ptoken / ptokenchar BNF.		o Corrected ptoken / ptokenchar BNF.
	o Disallow multiple title* parameters.		o Disallow multiple title* parameters.
	o Prefer title* over title when available.		o Prefer title* over title when available.
	o Remove "\" from ptokenchar.		o Remove "\" from ptokenchar.
	o Explain why mailing list isn't archived.		o Explain why mailing list isn't archived.
	o Define default language for title and title*, based on Content-		o Define default language for title and title*, based on Content-
	Language (when present).		Language (when present).
	o Adjust MAY requirements.		o Adjust MAY requirements.
	-08		-08
	o Licensed machine-readable data under MIT.		o Licensed machine-readable data under MIT.
	o Clarified URI comparison for extension relation types.		o Clarified URI comparison for extension relation types.
	o Various editorial tweaks (thanks, Julian!).		o Various editorial tweaks (thanks, Julian!).
	o Changed "fields" to "appdata" to avoid confusion, and add example		o Changed "fields" to "appdata" to avoid confusion, and add example
	to clarify.		to clarify.
	o Defined REV according to HTML2, deprecated.		o Defined REV according to HTML2, deprecated.
End of changes. 31 change blocks.
	84 lines changed or deleted		52 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/