draft-nottingham-http-link-header-09.txt		draft-nottingham-http-link-header-10.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: October 4, 2010		Expires: November 5, 2010
	Web Linking		Web Linking
	draft-nottingham-http-link-header-09		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		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 October 4, 2010.		This Internet-Draft will expire on November 5, 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 . . . . . . . . . . . . . 17		8. Internationalisation Considerations . . . . . . . . . . . . . 18
	9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18		9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
	9.1. Normative References . . . . . . . . . . . . . . . . . . . 18		9.1. Normative References . . . . . . . . . . . . . . . . . . . 18
	9.2. Informative References . . . . . . . . . . . . . . . . . . 18		9.2. Informative References . . . . . . . . . . . . . . . . . . 19
	Appendix A. Link Relation Registry Format . . . . . . . . . . . . 20		Appendix A. Link Relation Registry Format . . . . . . . . . . . . 21
	A.1. Relax NG Grammar . . . . . . . . . . . . . . . . . . . . . 20		A.1. Relax NG Grammar . . . . . . . . . . . . . . . . . . . . . 21
	A.2. Example . . . . . . . . . . . . . . . . . . . . . . . . . 21		A.2. Example . . . . . . . . . . . . . . . . . . . . . . . . . 22
	Appendix B. Notes on Using the Link Header with the HTML4		Appendix B. Notes on Using the Link Header with the HTML4
	Format . . . . . . . . . . . . . . . . . . . . . . . 21
	Appendix C. Notes on Using the Link Header with the Atom
	Format . . . . . . . . . . . . . . . . . . . . . . . 22		Format . . . . . . . . . . . . . . . . . . . . . . . 22
	Appendix D. Acknowledgements . . . . . . . . . . . . . . . . . . 23		Appendix C. Notes on Using the Link Header with the Atom
	Appendix E. Document history . . . . . . . . . . . . . . . . . . 23		Format . . . . . . . . . . . . . . . . . . . . . . . 23
	Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 27		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
	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-relation-type		Registered relation type names MUST conform to the reg-rel-type rule,
	rule, and MUST be compared character-by-character in a case-		and MUST be compared character-by-character in a case-insensitive
	insensitive fashion. They SHOULD be appropriate to the specificity		fashion. They SHOULD be appropriate to the specificity of the
	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 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-media-type ) )		| ( "type" "=" ( media-type | quoted-mt ) )
	| ( 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-media-type = <"> media-type <">		quoted-mt = <"> 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-rel-type | ext-rel-type
	reg-relation-type = LOALPHA *( LOALPHA | DIGIT | "." | "-" )		reg-rel-type = LOALPHA *( LOALPHA | DIGIT | "." | "-" )
	ext-relation-type = URI		ext-rel-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. Registration requests that are undetermined for a period		successful.
	longer than 21 days can be brought to the IESG's attention (using the
	iesg@iesg.org mailing list) for resolution.		Decisions (or lack thereof) made by the Designated Expert can be
			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 38		skipping to change at page 13, line 43
	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/>		o Reference: <http://pubsubhubbub.googlecode.com/> <http://
	o Notes: this relation type was requested by Brett Slakin.		pubsubhubbub.googlecode.com/svn/trunk/pubsubhubbub-core-0.3.html>
			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 28		skipping to change at page 14, line 35
	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.		reference. Requested by Joshua Kinberg and Robert Sayre. It is
			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: [I-D.brown-versioning-link-relations]		o Reference: [I-D.brown-versioning-link-relations]
	skipping to change at page 17, line 28		skipping to change at page 17, line 48
	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.		it. Use of TLS with HTTP ([RFC2818] and [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.
			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.
	skipping to change at page 19, line 9		skipping to change at page 19, line 35
	[I-D.brown-versioning-link-relations]		[I-D.brown-versioning-link-relations]
	Brown, A., Clemm, G., and J. Reschke, "Link Relation Types		Brown, A., Clemm, G., and J. Reschke, "Link Relation Types
	for Simple Version Navigation between Web Resources",		for Simple Version Navigation between Web Resources",
	draft-brown-versioning-link-relations-07 (work in		draft-brown-versioning-link-relations-07 (work in
	progress), January 2010.		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.
	[RFC4287] Nottingham, M. and R. Sayre, "The Atom Syndication		[RFC2817] Khare, R. and S. Lawrence, "Upgrading to TLS Within
	Format", RFC 4287, December 2005.		HTTP/1.1", RFC 2817, May 2000.
			[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
	skipping to change at page 23, line 41		skipping to change at page 24, 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. ]]
	-09		-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 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. 21 change blocks.
	37 lines changed or deleted		71 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/