< draft-ietf-tzdist-caldav-timezone-ref-03.txt		draft-ietf-tzdist-caldav-timezone-ref-04.txt >
	Network Working Group C. Daboo		Network Working Group C. Daboo
	Internet-Draft Apple		Internet-Draft Apple
	Intended status: Standards Track June 12, 2015		Updates: 4791 (if approved) August 31, 2015
	Expires: December 14, 2015		Intended status: Standards Track
			Expires: March 3, 2016
	CalDAV: Time Zones by Reference		CalDAV: Time Zones by Reference
	draft-ietf-tzdist-caldav-timezone-ref-03		draft-ietf-tzdist-caldav-timezone-ref-04
	Abstract		Abstract
	This document defines an extension to the CalDAV calendar access		This document defines an extension to the CalDAV calendar access
	protocol to allow clients and servers to exchange iCalendar data		protocol (RFC 4791) to allow clients and servers to exchange
	without the need to send full time zone data.		iCalendar data without the need to send full time zone data.
	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
	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). 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 December 14, 2015.		This Internet-Draft will expire on March 3, 2016.
	Copyright Notice		Copyright Notice
	Copyright (c) 2015 IETF Trust and the persons identified as the		Copyright (c) 2015 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 18 ¶		skipping to change at page 2, line 18 ¶
	2. Conventions Used in This Document . . . . . . . . . . . . . . 3		2. Conventions Used in This Document . . . . . . . . . . . . . . 3
	3. Time Zones by Reference . . . . . . . . . . . . . . . . . . . 3		3. Time Zones by Reference . . . . . . . . . . . . . . . . . . . 3
	3.1. New Server Behavior . . . . . . . . . . . . . . . . . . . 3		3.1. New Server Behavior . . . . . . . . . . . . . . . . . . . 3
	4. New Client Behavior . . . . . . . . . . . . . . . . . . . . . 7		4. New Client Behavior . . . . . . . . . . . . . . . . . . . . . 7
	5. New WebDAV Properties . . . . . . . . . . . . . . . . . . . . 8		5. New WebDAV Properties . . . . . . . . . . . . . . . . . . . . 8
	5.1. CALDAV:timezone-service-set . . . . . . . . . . . . . . . 8		5.1. CALDAV:timezone-service-set . . . . . . . . . . . . . . . 8
	5.2. CALDAV:calendar-timezone-id . . . . . . . . . . . . . . . 8		5.2. CALDAV:calendar-timezone-id . . . . . . . . . . . . . . . 8
	6. XML Element Definitions . . . . . . . . . . . . . . . . . . . 9		6. XML Element Definitions . . . . . . . . . . . . . . . . . . . 9
	6.1. CALDAV:calendar-query XML Element . . . . . . . . . . . . 9		6.1. CALDAV:calendar-query XML Element . . . . . . . . . . . . 9
	6.2. CALDAV:timezone-id XML Element . . . . . . . . . . . . . 9		6.2. CALDAV:timezone-id XML Element . . . . . . . . . . . . . 9
	7. Security Considerations . . . . . . . . . . . . . . . . . . . 10		7. Additional Message Header Fields . . . . . . . . . . . . . . 10
	8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10		7.1. CalDAV-Timezones Request Header Field . . . . . . . . . . 10
	9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10		8. Security Considerations . . . . . . . . . . . . . . . . . . . 10
	10. References . . . . . . . . . . . . . . . . . . . . . . . . . 10		9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
	10.1. Normative References . . . . . . . . . . . . . . . . . . 10		9.1. CalDAV-Timezones . . . . . . . . . . . . . . . . . . . . 10
	10.2. Informative References . . . . . . . . . . . . . . . . . 11		10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11
			11. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
			11.1. Normative References . . . . . . . . . . . . . . . . . . 11
			11.2. Informative References . . . . . . . . . . . . . . . . . 12
	Appendix A. Change History (To be removed by RFC Editor before		Appendix A. Change History (To be removed by RFC Editor before
	publication) . . . . . . . . . . . . . . . . . . . . 11		publication) . . . . . . . . . . . . . . . . . . . . 12
	Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 12		Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 13
	1. Introduction		1. Introduction
	The CalDAV [RFC4791] Calendar Access protocol allows clients to		The CalDAV [RFC4791] Calendar Access protocol allows clients to
	access calendar data stored on a server in the iCalendar [RFC5545]		access calendar data stored on a server in the iCalendar [RFC5545]
	data format. In iCalendar, calendar data that uses local time in any		data format. In iCalendar, calendar data that uses local time in any
	of its date and/or time values is specified as a date-time value in		of its date and/or time values is specified as a date-time value in
	combination with a time zone identifier ("TZID" property parameter).		combination with a time zone identifier ("TZID" property parameter).
	The time zone identifier refers to a time zone definition (a		The time zone identifier refers to a time zone definition (a
	"VTIMEZONE" component) that has all of the rules required to		"VTIMEZONE" component) that has all of the rules required to
	skipping to change at page 3, line 46 ¶		skipping to change at page 3, line 51 ¶
	sent or received via the CalDAV protocol (both [RFC4791] and		sent or received via the CalDAV protocol (both [RFC4791] and
	[RFC6638], and extensions). These changes do not apply to other		[RFC6638], and extensions). These changes do not apply to other
	means of exchanging calendar data, such as iTIP [RFC5546] based		means of exchanging calendar data, such as iTIP [RFC5546] based
	scheduling mechanisms (e.g., iMIP [RFC6047]), or other methods.		scheduling mechanisms (e.g., iMIP [RFC6047]), or other methods.
	3.1. New Server Behavior		3.1. New Server Behavior
	3.1.1. Server Advertised Capability		3.1.1. Server Advertised Capability
	A server that supports this specification MUST include "calendar-no-		A server that supports this specification MUST include "calendar-no-
	timezone" as a field in the DAV response header from an OPTIONS		timezone" as a field in the DAV response header field from an OPTIONS
	request on a calendar home collection (see Section 6.2.1 of		request on a calendar home collection (see Section 6.2.1 of
	[RFC4791]) or calendar collection (see Section 4.2 of [RFC4791]).		[RFC4791]) or calendar collection (see Section 4.2 of [RFC4791]).
	Clients MUST check for the presence of that field in the DAV response		Clients MUST check for the presence of that field in the DAV response
	header before changing their behavior as per Section 4.		header field before changing their behavior as per Section 4.
	3.1.2. Associated Time Zone Data Distribution Service		3.1.2. Associated Time Zone Data Distribution Service
	A CalDAV server supporting this specification MUST have one or more		A CalDAV server supporting this specification MUST have one or more
	associated time zone distribution services [I-D.ietf-tzdist-service]		associated time zone distribution services [I-D.ietf-tzdist-service]
	that provide data for the set of time zones known to the server and		that provide data for the set of time zones known to the server and
	expected to be used by clients. A CalDAV server advertises the set		expected to be used by clients. A CalDAV server advertises the set
	of time zone distribution services it makes use of via a		of time zone distribution services it makes use of via a
	CALDAV:timezone-service-set WebDAV property (see Section 5.1) defined		CALDAV:timezone-service-set WebDAV property (see Section 5.1) defined
	on calendar home collections. Clients can use the time zone data		on calendar home collections. Clients can use the time zone data
	skipping to change at page 4, line 32 ¶		skipping to change at page 4, line 36 ¶
	being used.		being used.
	When making use of the time zone data distribution services		When making use of the time zone data distribution services
	advertised by a CalDAV server, clients MUST follow all the		advertised by a CalDAV server, clients MUST follow all the
	requirements of the time zone data distribution service protocol		requirements of the time zone data distribution service protocol
	[I-D.ietf-tzdist-service], taking care to refresh time zone data in a		[I-D.ietf-tzdist-service], taking care to refresh time zone data in a
	timely fashion.		timely fashion.
	3.1.3. Time Zones in CalDAV Responses		3.1.3. Time Zones in CalDAV Responses
	Servers MUST support the HTTP "Prefer" header [RFC7240] with		Servers MUST support the HTTP "CalDAV-Timezones" request header field
	"vtimezone=yes" and "vtimezone=no" preference values (see Section 8).		(see Section 7.1). If the "CalDAV-Timezones" request header field
	If the "vtimezone=yes" preference is set by a client on any HTTP		has the value "T" on any HTTP request that returns iCalendar data,
	request that returns iCalendar data, then the server MUST include all		then the server MUST include all the appropriate "VTIMEZONE"
	the appropriate "VTIMEZONE" components in the iCalendar data (all the		components in the iCalendar data (all the ones that are referenced by
	ones that are referenced by "TZID" property parameters). If the		"TZID" property parameters). If the "CalDAV-Timezones" request
	"vtimezone=no" preference is set by a client on any HTTP request that		header field has the value "F" on any HTTP request that returns
	returns iCalendar data, then the server MUST NOT return any		iCalendar data, then the server MUST NOT return any "VTIMEZONE"
	"VTIMEZONE" components if the time zone identifier matches one		components if the time zone identifier matches one provided by any of
	provided by any of the advertised time zone distribution servers (see		the advertised time zone distribution servers (see Section 3.1.2).
	Section 3.1.2). However, the server MUST return the appropriate		However, the server MUST return the appropriate "VTIMEZONE" component
	"VTIMEZONE" component for each time zone with an identifier not		for each time zone with an identifier not available on the advertised
	available on the advertised time zone distribution servers. This		time zone distribution servers. This behaviour applies to all HTTP
	behaviour applies to all HTTP requests on CalDAV resources that		requests on CalDAV resources that return iCalendar data either
	return iCalendar data either directly (such as a "GET" request on a		directly (such as a "GET" request on a calendar object resource), or
	calendar object resource), or embedded in a "structured" response		embedded in a "structured" response such as a DAV:multistatus
	such as a DAV:multistatus returned by a "REPORT" or "PROPFIND"		returned by a "REPORT" or "PROPFIND" request.
	request.
	Observation and experiments have shown that, in the vast majority of		Observation and experiments have shown that, in the vast majority of
	cases, CalDAV clients have typically ignored time zone definitions in		cases, CalDAV clients have typically ignored time zone definitions in
	data received from servers, and instead make use of their own "built-		data received from servers, and instead make use of their own "built-
	in" definitions for the corresponding time zone identifier. This		in" definitions for the corresponding time zone identifier. This
	means that it is reasonable for CalDAV servers to unilaterally decide		means that it is reasonable for CalDAV servers to unilaterally decide
	not to send "VTIMEZONE" components for standard time zones that		not to send "VTIMEZONE" components for standard time zones that
	clients are expected to have "built-in" (i.e., IANA time zones).		clients are expected to have "built-in" (i.e., IANA time zones).
	Thus, in the absence of an explicit "vtimezone=yes" or "vtimezone=no"		Thus, in the absence of a "CalDAV-Timezones" request header field,
	preference in the request from a client, servers advertizing the		servers advertizing the "calendar-no-timezone" capability MAY opt to
	"calendar-no-timezone" capability MAY opt to not send standard		not send standard "VTIMEZONE" components. Servers that do that will
	"VTIMEZONE" components.		need to provide an administrator configuration setting to override
			the new default behavior based on client "User-Agent" request header
			field field values, or other suitable means of identifying the client
			software in use.
	3.1.4. Time Zones in CalDAV Requests		3.1.4. Time Zones in CalDAV Requests
	In addition to servers not sending time zone definitions to clients		In addition to servers not sending time zone definitions to clients
	in iCalendar data, this specification also allows clients to not		in iCalendar data, this specification also allows clients to not
	include time zone definitions when sending iCalendar data to the		include time zone definitions when sending iCalendar data to the
	server, as per Section 4. This behaviour applies to all HTTP		server, as per Section 4. This behaviour applies to all HTTP
	requests on CalDAV resources that include iCalendar data either		requests on CalDAV resources that include iCalendar data either
	directly in the request body (such as a "PUT" request on a calendar		directly in the request body (such as a "PUT" request on a calendar
	object resource), or embedded in a "structured" request body such as		object resource), or embedded in a "structured" request body such as
	skipping to change at page 7, line 10 ¶		skipping to change at page 7, line 15 ¶
	If a client attempts use a CALDAV:timezone-id XML element with a		If a client attempts use a CALDAV:timezone-id XML element with a
	value that does not correspond to a time zone that is known to the		value that does not correspond to a time zone that is known to the
	server, the server MUST reject the request with a CALDAV:valid-		server, the server MUST reject the request with a CALDAV:valid-
	timezone pre-condition error. In such cases, clients MAY repeat the		timezone pre-condition error. In such cases, clients MAY repeat the
	request using the CALDAV:timezone XML element instead, and provide		request using the CALDAV:timezone XML element instead, and provide
	the full iCalendar data for the time zone being used.		the full iCalendar data for the time zone being used.
	4. New Client Behavior		4. New Client Behavior
	When a server advertises the "calendar-no-timezone" field in a DAV		When a server advertises the "calendar-no-timezone" field in a DAV
	response header (as per Section 3.1.1):		response header field (as per Section 3.1.1):
	1. Clients SHOULD include an HTTP "Prefer" header with a		1. Clients SHOULD include an HTTP "CalDAV-Timezones" request header
	"vtimezone=no" preference to ensure that the CalDAV server does		field with a value of "F" to ensure that the CalDAV server does
	not include "VTIMEZONE" components in any iCalendar data returned		not include "VTIMEZONE" components in any iCalendar data returned
	in a response (see Section 3.1.3, for those time zones whose		in a response (see Section 3.1.3), for those time zones whose
	identifier is one provided by any of the advertised time zone		identifier is one provided by any of the advertised time zone
	distribution servers (see Section 3.1.2). In this case, clients		distribution servers (see Section 3.1.2). In this case, clients
	MUST retrieve the missing standard time zone definitions from the		will have to retrieve the missing standard time zone definitions
			either from their own cache of standard time zones, or from the
	set of time zone distribution servers advertised by the CalDAV		set of time zone distribution servers advertised by the CalDAV
	server (see Section 3.1.2).		server (see Section 3.1.2).
	2. Clients can include an HTTP "Prefer" header with a		2. Clients can include an HTTP "CalDAV-Timezones" request header
	"vtimezone=yes" preference to ensure that the CalDAV server does		field with a value of "T" to ensure that the CalDAV server does
	include all "VTIMEZONE" components in any iCalendar data returned		include all "VTIMEZONE" components in any iCalendar data returned
	in a response (see Section 3.1.3).		in a response (see Section 3.1.3).
	3. Clients can expect servers not to include standard time zone		3. Clients can expect servers not to include standard time zone
	definitions in any iCalendar data they receive from the server,		definitions in any iCalendar data they receive from the server,
	if no "vtimezone=yes" and no "vtimezone=no" preference is set in		if there is no "CalDAV-Timezones" request header field in the
	the HTTP request. Clients MUST retrieve standard time zone		HTTP request. Clients MUST retrieve standard time zone
	definitions from the set of time zone distribution servers		definitions from the set of time zone distribution servers
	advertised by the CalDAV server (see Section 3.1.2), or a known.		advertised by the CalDAV server (see Section 3.1.2), or a known.
	4. Clients SHOULD remove standard time zone definitions from		4. Clients SHOULD remove standard time zone definitions from
	iCalendar data they send to the server, provided the		iCalendar data they send to the server, provided the
	corresponding time zone identifier is one available on any of the		corresponding time zone identifier is one available on any of the
	server's advertised time zone distribution servers (see		server's advertised time zone distribution servers (see
	Section 3.1.2).		Section 3.1.2).
	5. Clients MUST send time zone definitions in iCalendar data for any		5. Clients MUST send time zone definitions in iCalendar data for any
	skipping to change at page 10, line 10 ¶		skipping to change at page 10, line 17 ¶
	[RFC4791]) in calendar query reports, to allow a client to specify		[RFC4791]) in calendar query reports, to allow a client to specify
	a time zone using a time zone identifier rather than providing the		a time zone using a time zone identifier rather than providing the
	full iCalendar time zone data. See Section 3.1.6 for more		full iCalendar time zone data. See Section 3.1.6 for more
	details.		details.
	Definition:		Definition:
	<!ELEMENT timezone-id (#PCDATA)>		<!ELEMENT timezone-id (#PCDATA)>
	PCDATA value: an time zone identifier.		PCDATA value: an time zone identifier.
	7. Security Considerations		7. Additional Message Header Fields
			7.1. CalDAV-Timezones Request Header Field
			The "CalDAV-Timezones" request header field provides a way for a
			client to indicate to the server whether it wants "VTIMEZONE"
			components returned in any iCalendar data that is part of the HTTP
			response. The value "T" indicates that the client wants time zone
			data returned, the value "F" indicates that it does not.
			CalDAV-Timezones = "T" / "F"
			Example:
			CalDAV-Timezones: F
			8. Security Considerations
	This specification does not introduce any new security concerns		This specification does not introduce any new security concerns
	beyond those addressed in CalDAV [RFC4791] and iCalendar [RFC5545].		beyond those addressed in CalDAV [RFC4791] and iCalendar [RFC5545].
	8. IANA Considerations		9. IANA Considerations
	IANA is requested to add the following registration to the "HTTP		The message header field below should be added to the Permanent
	Preferences" registry defined by [RFC7240].		Message Header Field Registry (see [RFC3864]).
	Preference: vtimezone		9.1. CalDAV-Timezones
	Value: One of either "yes" or "no"		Header field name: CalDAV-Timezones
	Description: Indicates whether the client prefers a CalDAV server		Applicable protocol: http
	to send "VTIMEZONE" iCalendar components in responses.
	Reference: [this RFC], Section 3.1.3.		Status: standard
	9. Acknowledgments		Author/Change controller: IETF
			Specification document(s): this specification (Section 7.1)
			Related information: none
			10. Acknowledgments
	Thanks to Mike Douglass, Andrew McMillan, and Ken Murchison. This		Thanks to Mike Douglass, Andrew McMillan, and Ken Murchison. This
	specification came about via discussions at the Calendaring and		specification came about via discussions at the Calendaring and
	Scheduling Consortium.		Scheduling Consortium.
	10. References		11. References
	10.1. Normative References		11.1. Normative References
	[I-D.ietf-tzdist-service]		[I-D.ietf-tzdist-service]
	Douglass, M. and C. Daboo, "Time Zone Data Distribution		Douglass, M. and C. Daboo, "Time Zone Data Distribution
	Service", draft-ietf-tzdist-service-08 (work in progress),		Service", draft-ietf-tzdist-service-11 (work in progress),
	June 2015.		July 2015.
	[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, DOI 10.17487/
			RFC2119, March 1997,
			<http://www.rfc-editor.org/info/rfc2119>.
			[RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration
			Procedures for Message Header Fields", BCP 90, RFC 3864,
			DOI 10.17487/RFC3864, September 2004,
			<http://www.rfc-editor.org/info/rfc3864>.
	[RFC4791] Daboo, C., Desruisseaux, B., and L. Dusseault,		[RFC4791] Daboo, C., Desruisseaux, B., and L. Dusseault,
	"Calendaring Extensions to WebDAV (CalDAV)", RFC 4791,		"Calendaring Extensions to WebDAV (CalDAV)", RFC 4791, DOI
	March 2007.		10.17487/RFC4791, March 2007,
			<http://www.rfc-editor.org/info/rfc4791>.
	[RFC4918] Dusseault, L., "HTTP Extensions for Web Distributed		[RFC4918] Dusseault, L., Ed., "HTTP Extensions for Web Distributed
	Authoring and Versioning (WebDAV)", RFC 4918, June 2007.		Authoring and Versioning (WebDAV)", RFC 4918, DOI
			10.17487/RFC4918, June 2007,
			<http://www.rfc-editor.org/info/rfc4918>.
	[RFC5545] Desruisseaux, B., "Internet Calendaring and Scheduling		[RFC5545] Desruisseaux, B., Ed., "Internet Calendaring and
	Core Object Specification (iCalendar)", RFC 5545,		Scheduling Core Object Specification (iCalendar)", RFC
	September 2009.		5545, DOI 10.17487/RFC5545, September 2009,
			<http://www.rfc-editor.org/info/rfc5545>.
	[RFC6638] Daboo, C. and B. Desruisseaux, "Scheduling Extensions to		[RFC6638] Daboo, C. and B. Desruisseaux, "Scheduling Extensions to
	CalDAV", RFC 6638, June 2012.		CalDAV", RFC 6638, DOI 10.17487/RFC6638, June 2012,
			<http://www.rfc-editor.org/info/rfc6638>.
	[RFC7240] Snell, J., "Prefer Header for HTTP", RFC 7240, June 2014.
	10.2. Informative References		11.2. Informative References
	[RFC5546] Daboo, C., "iCalendar Transport-Independent		[RFC5546] Daboo, C., Ed., "iCalendar Transport-Independent
	Interoperability Protocol (iTIP)", RFC 5546, December		Interoperability Protocol (iTIP)", RFC 5546, DOI 10.17487/
	2009.		RFC5546, December 2009,
			<http://www.rfc-editor.org/info/rfc5546>.
	[RFC6047] Melnikov, A., "iCalendar Message-Based Interoperability		[RFC6047] Melnikov, A., Ed., "iCalendar Message-Based
	Protocol (iMIP)", RFC 6047, December 2010.		Interoperability Protocol (iMIP)", RFC 6047, DOI 10.17487/
			RFC6047, December 2010,
			<http://www.rfc-editor.org/info/rfc6047>.
	[RFC6557] Lear, E. and P. Eggert, "Procedures for Maintaining the		[RFC6557] Lear, E. and P. Eggert, "Procedures for Maintaining the
	Time Zone Database", BCP 175, RFC 6557, February 2012.		Time Zone Database", BCP 175, RFC 6557, DOI 10.17487/
			RFC6557, February 2012,
			<http://www.rfc-editor.org/info/rfc6557>.
	Appendix A. Change History (To be removed by RFC Editor before		Appendix A. Change History (To be removed by RFC Editor before
	publication)		publication)
			Changes in -04:
			1. AD Review: added Updates 4791
			2. AD Review: reworded first bullet of Section 4 to indicate clients
			have a choice of where to locate time zones
			3. AD Review: added text about server providing an admin config
			option to override new default behavior
			4. AD Review: Replaced Prefer header with CalDAV-Timezones
	Changes in -03:		Changes in -03:
	1. Chair Review: minor editorial changes		1. Chair Review: minor editorial changes
	2. Chair Review: expanded item #3 in Section 3.1.4 to clarify the		2. Chair Review: expanded item #3 in Section 3.1.4 to clarify the
	behavior and indicate when it would not be appropriate.		behavior and indicate when it would not be appropriate.
	Changes in -02:		Changes in -02:
	1. Ticket #27: added an HTTP Prefer header preference to allow		1. Ticket #27: added an HTTP Prefer header preference to allow
End of changes. 38 change blocks.
	79 lines changed or deleted		134 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/