draft-nottingham-http-link-header-08.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: September 2, 2010		Expires: October 4, 2010
	Web Linking		Web Linking
	draft-nottingham-http-link-header-08		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 to IETF in full conformance with the		This Internet-Draft is submitted in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF), its areas, and its working groups. Note that		Task Force (IETF). Note that other groups may also distribute
	other groups may also distribute working documents as Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts.		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."
	The list of current Internet-Drafts can be accessed at		This Internet-Draft will expire on October 4, 2010.
	http://www.ietf.org/ietf/1id-abstracts.txt.
	The list of Internet-Draft Shadow Directories can be accessed at
	http://www.ietf.org/shadow.html.
	This Internet-Draft will expire on September 2, 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
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	described in the BSD License.		described in the Simplified BSD License.
	This document may contain material from IETF Documents or IETF		This document may contain material from IETF Documents or IETF
	Contributions published or made publicly available before November		Contributions published or made publicly available before November
	10, 2008. The person(s) controlling the copyright in some of this		10, 2008. The person(s) controlling the copyright in some of this
	material may not have granted the IETF Trust the right to allow		material may not have granted the IETF Trust the right to allow
	modifications of such material outside the IETF Standards Process.		modifications of such material outside the IETF Standards Process.
	Without obtaining an adequate license from the person(s) controlling		Without obtaining an adequate license from the person(s) controlling
	the copyright in such materials, this document may not be modified		the copyright in such materials, this document may not be modified
	outside the IETF Standards Process, and derivative works of it may		outside the IETF Standards Process, and derivative works of it may
	not be created outside the IETF Standards Process, except to format		not be created outside the IETF Standards Process, except to format
	skipping to change at page 4, 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 from [I-D.reschke-rfc2231-in-http], 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 IRIs [RFC3987], and is comprised of:
	o A context IRI, and		o A context IRI, and
	o a link relation type (Section 4), and		o a link relation type (Section 4), and
	o a target IRI, and		o a target IRI, and
	o optionally, target attributes.		o optionally, target attributes.
	skipping to change at page 6, line 37		skipping to change at page 5, line 37
	Registered relation type names MUST conform to the reg-relation-type		Registered relation type names MUST conform to the reg-relation-type
	rule, and MUST be compared character-by-character in a case-		rule, and MUST be compared character-by-character in a case-
	insensitive fashion. They SHOULD be appropriate to the specificity		insensitive fashion. They SHOULD be appropriate to the specificity
	of the 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 MAY 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).
	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 MAY 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 may 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.
	When extension relation types are compared, they MUST be compared as		When extension relation types are compared, they MUST be compared as
	strings (after converting to URIs if serialised in a different		strings (after converting to URIs if serialised in a different
	format, such as a Curie [W3C.CR-curie-20090116]) in a case-		format, such as a Curie [W3C.CR-curie-20090116]) in a case-
	insensitive fashion, character-by-character. Because of this, all-		insensitive fashion, character-by-character. Because of this, all-
	skipping to change at page 8, line 16		skipping to change at page 7, line 16
	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-media-type ) )		| ( "type" "=" ( media-type | quoted-media-type ) )
	| ( link-extension ) )		| ( link-extension ) )
	link-extension = ( token [ "=" ( ptoken | quoted-string ) ] )		link-extension = ( parmname [ "=" ( ptoken | quoted-string ) ] )
	| ( ext-name-star "=" ext-value )		| ( ext-name-star "=" ext-value )
	ext-name-star = token "*" ; 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 = "!" | "#" | "$" | "%" | "&" | "'" | "("		ptoken = 1*ptokenchar
			ptokenchar = "!" | "#" | "$" | "%" | "&" | "'" | "("
	| ")" | "*" | "+" | "-" | "." | "/" | DIGIT		| ")" | "*" | "+" | "-" | "." | "/" | DIGIT
	| ":" | "<" | "=" | ">" | "?" | "@" | ALPHA		| ":" | "<" | "=" | ">" | "?" | "@" | ALPHA
	| "[" | "\" | "]" | "^" | "_" | "`" | "{"		| "[" | "]" | "^" | "_" | "`" | "{" | "|"
	| "|" | "}" | "~"		| "}" | "~"
	media-type = type-name "/" subtype-name		media-type = type-name "/" subtype-name
	quoted-media-type = <"> 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-relation-type | ext-relation-type		relation-type = reg-relation-type | ext-relation-type
	reg-relation-type = LOALPHA *( LOALPHA | DIGIT | "." | "-" )		reg-relation-type = LOALPHA *( LOALPHA | DIGIT | "." | "-" )
	ext-relation-type = URI		ext-relation-type = URI
	5.1. Target IRI		5.1. Target IRI
	skipping to change at page 9, line 5		skipping to change at page 8, line 6
	By default, the context of a link conveyed in the Link header field		By default, the context of a link conveyed in the Link header field
	is the IRI of the requested resource.		is the IRI of the requested resource.
	When present, the anchor parameter overrides this with another URI,		When present, the anchor parameter overrides this with another URI,
	such as a fragment of this resource, or a third resource (i.e., when		such as a fragment of this resource, or a third resource (i.e., when
	the anchor value is an absolute URI). If the anchor parameter's		the anchor value is an absolute URI). If the anchor parameter's
	value is a relative URI, parsers MUST resolve it as per [RFC3986],		value is a relative URI, parsers MUST resolve it as per [RFC3986],
	Section 5. Note that any base URI from the body's content is not		Section 5. Note that any base URI from the body's content is not
	applied.		applied.
	Consuming implementations may choose to ignore links with an anchor		Consuming implementations can choose to ignore links with an anchor
	parameter. For example, the application in use may not allow the		parameter. For example, the application in use may not allow the
	context IRI to be assigned to a different resource. In such cases,		context IRI to be assigned to a different resource. In such cases,
	the entire link is to be ignored; consuming implementations MUST NOT		the entire link is to be ignored; consuming implementations MUST NOT
	process the link without applying the anchor.		process the link without applying the anchor.
	Note that depending on HTTP status code and response headers, the		Note that depending on HTTP status code and response headers, the
	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
	skipping to change at page 10, line 7		skipping to change at page 9, line 9
	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). The "title" parameter MUST NOT appear more than		(e.g. a menu entry) in the language indicated by the Content-Language
			header (if present). The "title" parameter MUST NOT appear more than
	once in a given link-value; occurrences after the first MUST be		once in a given link-value; occurrences after the first MUST be
	ignored by parsers.		ignored by parsers.
	The "title*" parameter MAY 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 MAY appear		[I-D.reschke-rfc2231-in-http]. The "title*" parameter MUST NOT
	more than once in a given link-value, but each occurrence MUST		appear more than once in a given link-value; occurrences after the
	indicate a different language; occurrences after the first for a		first MUST be ignored by parsers. If the parameter does not contain
	given language MUST be ignored by parsers.		language information, its language is indicated by the Content-
			Language header (when present).
	When presenting links to users, agents SHOULD use the most		If both the "title" and "title*" parameters appear in a link-value,
	appropriate "title*" value, according to user preferences. If an		processors SHOULD use the "title*" parameter's value.
	appropriate "title*" value cannot be found, the "title" parameter's
	value, if available, can be used.
	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.
	5.5. Examples		5.5. Examples
	skipping to change at page 11, line 14		skipping to change at page 10, line 14
	Link: </TheBook/chapter2>;		Link: </TheBook/chapter2>;
	rel="previous"; title*=UTF-8'de'letztes%20Kapitel,		rel="previous"; title*=UTF-8'de'letztes%20Kapitel,
	</TheBook/chapter4>;		</TheBook/chapter4>;
	rel="next"; title*=UTF-8'de'n%c3%a4chstes%20Kapitel		rel="next"; title*=UTF-8'de'n%c3%a4chstes%20Kapitel
	Here, both links have titles encoded in UTF-8, use the German		Here, both links have titles encoded in UTF-8, use the German
	language ("de"), and the second link contains the Unicode code point		language ("de"), and the second link contains the Unicode code point
	U+00E4 ("LATIN SMALL LETTER A WITH DIAERESIS").		U+00E4 ("LATIN SMALL LETTER A WITH DIAERESIS").
	Note that link-values may convey multiple links between the same		Note that link-values can convey multiple links between the same
	target and context IRIs; for example:		target and context IRIs; for example:
	Link: <http://example.org/>;		Link: <http://example.org/>;
	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
	skipping to change at page 12, line 48		skipping to change at page 11, line 48
	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(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, and		ietf.org mailing list (which SHOULD NOT be centrally archived, so as
	only accept posts from the Designated Expert(s)), so that		to avoid load issues from automated agents, and only accept posts
	implementers interested in receiving a machine-readable registry can		from the Designated Expert(s)), so that implementers interested in
	do so. Simultaneously, they will send a text (not XML) version of		receiving a machine-readable registry can do so. Simultaneously,
	the registry to IANA for publication.		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
	skipping to change at page 18, line 16		skipping to change at page 17, line 16
	possible).		possible).
	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 APP DATA").		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 MAY 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
	skipping to change at page 19, line 12		skipping to change at page 18, line 12
	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., "Application of RFC 2231 Encoding to		Reschke, J., "Application of RFC 2231 Encoding to
	Hypertext Transfer Protocol (HTTP) Header Fields",		Hypertext Transfer Protocol (HTTP) Header Fields",
	draft-reschke-rfc2231-in-http-09 (work in progress),		draft-reschke-rfc2231-in-http-11 (work in progress),
	February 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 24, line 21		skipping to change at page 23, line 21
	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, lower case) 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 may 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 D. Acknowledgements
	This specification lifts the idea and definition for the Link header		This specification lifts the idea and definition for the Link header
	from RFC2068; credit for it belongs entirely to the authors of and		from RFC2068; credit for it belongs entirely to the authors of and
	contributors to that document. The link relation 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		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. ]]
			-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		-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.
	o Clarified allowable characters in link-extensions.		o Clarified allowable characters in link-extensions.
	o Changed RFC2231 reference to draft-reschke-rfc2231-in-http.		o Changed RFC2231 reference to draft-reschke-rfc2231-in-http.
	o Added hub, latest-version, predecessor-version, successor-version,		o Added hub, latest-version, predecessor-version, successor-version,
	version-history, working-copy and working-copy-of relation types		version-history, working-copy and working-copy-of relation types
	to initial registry.		to initial registry.
			o Adjusted text regarding when anchor parameter is appropriate.
	-07		-07
	o Allowed multiple spaces between relation types.		o Allowed multiple spaces between relation types.
	o Relaxed requirements for registered relations.		o Relaxed requirements for registered relations.
	o Removed Defining New Link Serialisations appendix.		o Removed Defining New Link Serialisations appendix.
	o Added Field registry.		o Added Field registry.
	o Added registry XML format.		o Added registry XML format.
	o Changed registration procedure to use mailing list(s), giving the		o Changed registration procedure to use mailing list(s), giving the
	Designated Experts more responsibility for the smooth running of		Designated Experts more responsibility for the smooth running of
End of changes. 27 change blocks.
	45 lines changed or deleted		53 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/